Resolve environment variables embedded in a xml file saved in the registry in WSO2 MI

I am using the Micro Integrator 4.1.0 of WSO2.

I have added environment variables in my server (a pod in Kubernetes and I add the variables in a file that the pod read when it is deploying) and it's working fine with sequences (using $SYSTEM:variable_name) and with endpoints ($SYSTEM too).

My problem is that I have tried to add a environment variable in a simple XML file saved in a Registry project but it doesn't work.

I have tried the next 2 options:

<root>
    <Backend>
        <usuario>$SYSTEM:USER</usuario>
        <password>$SYSTEM:PASS</password>
    </Backend>
</root>

-

<root>
    <Backend>
        <usuario>${USER}</usuario>
        <password>${PASS}</password>
    </Backend>
</root>

When I read the file in a sequence the value that I am getting is the hardcoded value (for example: ${USER})

Is that possible or exists any trick?

This is not possible. Since this is just a registry file, MI won't resolve the variables during the deployment. Instead, you will need to read the system variables in the sequence and carry out the mediation. What is the requirement to read the file in the sequence? If are planning to send the XML content in the above file to an endpoint, you can use the payload factory to generate the required request body dynamically.

As Sanoj mentioned you can solve this with a PL Factory mediator. But since you asked for a trick, here is a hacky way to do it

You can do something like the below with Script Mediator.

The Payload

<root>
    <Backend>
        <usuario>{USER}</usuario>
        <password>{PASS}</password>
    </Backend>
</root>

Script

<script language="js"><![CDATA[ 
	var pl = mc.getPayloadXML().toString();
	var props = pl.match(new RegExp(/\{(.*)\}/g));
	for(var i = 0; i < props.length; i++) {
		var proName = props[i].replace('{', '').replace('}', '').trim();
		pl = pl.replace(props[i], java.lang.System.getenv(proName));       
	}
	mc.setPayloadXML(new XML(pl));
	]]>
</script>

I was too lazy to traverse the Payload as a XML tree and went for a regex based solution. I believe you get the idea here, so you can build on top of this. You can consider writing a Class Mediator as well.