Over the past couple of years, I have been involved in more and more projects and proofs-of-concept moving assets from Oracle SOA Suite to Oracle Integration Cloud.
Now it is important to note that these are quite different products and serve different needs. SOA Suite is a very extensive tool which allows you to create apps, user interfaces, integrations and much more. Oracle Integration Cloud (OIC) is more focused on just integration. However, many companies have used SOA Suite simply for integration purposes and making the move to OIC attractive.
There are many actions in the world of BPEL that don't yet exist in OIC, but one that is particularly troublesome is the lack of local variables. It is often convenient in BPEL to use a local variable to make future mappings easier in the integration. SOA Suite's BPEL lets you create arbitrary variables of any shape and size based on a schema definition. In OIC, local variables are either a string or based on a trigger or invoke operation.
The new Data Stitch action almost gets us there, but again, the stitch variable must be a type already defined by a trigger or invoke. You can't define a schema for the variable if it does not already exist.
STAGE FILE to the rescue!!!
As you may know, you can use the stage file action to create a file on the local, in-memory, temporary filesystem. This is very handy when manipulating files, performing zip and unzip operations and preparing files for file based integrations such as ERP Cloud. But it can also be used to create temporary, local variables!
First, create a stage action to write the file:
I typically give it a name like the variable type and put it in a "/tmp" directory.
Now I'm able to define the schema for the local variable. Of course, you can use an XSD, JSON Sample, XML Sample or EDI document.
In this case, I'll just use a sample json.
Now we can map values to the file based on the schema definition.
Now we can use the stage action to read the contents back in. We can use the reference from the write operation.
And, use the same schema that was used for the write operation.
You can now use the response from the Read operation as if it was a local variable. You can also use this response to define a data-stitch variable.
You can wrap these steps inside a scope to "hide" the complexity and use the variable outside the scope using the data stitch.
Many times, it is nice to create several "local" variables before doing your final mapping. This can make it much easier to map and maintain.
Keep on integrating!