DECIPHER: Dynamic XSLTs in BPEL (SOA 12c)

 While developing integrations in BPEL 12c, XSLT is most commonly used to transform different XML message structures. We generally come across scenarios wherein based on specific input fields, our transformation logic changes. What we generally do is have all conditions within the same XSLT file. This makes our XSLT look a lot bigger and difficult to maintain. A better way would be to have different XSLTs and move deciding factor out of XSLT. Once we create different XSLTs for specific use cases having the same output format, now the question will come how to configure these XSLTs to be picked at runtime? This blog is curated with answers to such and many more questions.

Let's take the example of account creation. There is a source application sending account information in an XML document which we need to update in a backend database. Now source system can send different types of address information like home address, business address, or shipping address. We get this information in the addressType input field. In the backend database, for each type of address, there are different fields in the backend database. There could various ways to handle this.

1. Create one single XSLT to handle all the scenarios using XSLT functions like if, choose-when, etc. One single XSLT file for all the scenarios, BPEL code will be easy to read. But this will lead to a huge XSLT file and will be a bit tricky to maintain. In the future, if we want to add new conditions for only secondary addresses, then regression testing might be required to ensure we don't hamper the other functionality.

2. Another way could be to have separate XSLTs for each scenario. As per the example, we have 3 scenarios. The address can be of type home, business, or shipping address.

We can have 3 XSLTs created for each scenario. Now maintainability of Transformation XSLT code will be a lot easier. These can now be configured using an if-else block within the BPEL process to decide which XSLT to pick. The BPEL process will look now similar to below.

3. Now suppose tomorrow we have a new condition added, then we need to add another block of "elseif" to accommodate this. This will make your BPEL code look bigger.
In SOA 12c we have below two functions that can be used to shorten the BPEL flow and use the XSLT dynamically. 
  • ora:processXSLT
  • ora:doXSLTransformForDoc
xmlns:ora="http://schemas.oracle.com/xpath/extension"

Both of the above functions support the location of the XSLT file and input XML. The above functions can be used in conjunction with DVM to fetch the location of XSLT and assign it to the input of the function.
For the same example, let's consider below DVM file as an example.


We can use the above DVM file to extract the location of XSLT that can be used. Suppose we store the conditional value in a variable called $addType(having one of the values in the home, business, or shipping). We can use DVM lookup to fetch the resulting XSLT file location that can be provided as input to the above-mentioned functions in an Assign activity. In case none of the conditions matches the default.xsl file can be used.

dvm:lookupValue("dvms/dynamicXSLT.dvm", "addressType",$addType, "xsltLocation", "transformations/default.xsl")

Let us assume the output value of the above expression is stored in variable $dynamicXSLT and input XML is stored in $input. The expression will be:

ora:processXSLT($dynamicXSLT, $input)
ora:doXSLTransformForDoc($dynamicXSLT, $input)

Both the above functions do a similar task. But there is one major difference. Suppose your XSLT requires extra complex parameters to be passed as input. In such scenarios ora:doXSLTransformForDoc comes real handy. In this function, we can pass key-value pairs of parameters that can be used within the XSLT.

For example, if our XSLT requires a parameter contact(as defined in XSLT) and the value is stored in the $Contact variable in the BPEL process. Now our function will look like.

ora:doXSLTransformForDoc($dynamicXSLT, $input, 'contact', $contact)

References:


Please share your valuable feedback 😊😊😊



-

Comments

Post a Comment

Popular posts from this blog

DateTime formatting using xp20:format-dateTime ()

xs:dateTime Format In XML, we generally use xs:dateTime(xs:xmlns="http://www.w3.org/2001/XMLSchema") data type to store date time data. The generic representation of date time, that is supported by xs:dateTime in xml: YYYY-MM-DDThh:mm:ss[.SSS][Z|(+|-)hh:mm] Example :  2019-09-11T10:16:31.943+05:30 Code Description Example YYYY represents a 4-digit year 2019 MM represents a 2-digit month 09 DD represents 2-digit date 11 hh represents 2-digit hours 10 mm represents minutes in 2-digits 16 ss represents seconds in 2-digits 31 SSS represents milliseconds 943 T represents time separator T Z represents UTC time zone or 0 time zone offset (+|-)hh:mm represents time zone offset +5:30 Few more valid examples : 2019-09-11T21:32:52, 2019-09-11T21:32:52+02:
Read more

Create Delimited String from XML Nodes and Vice Versa in SOA 12c

A delimited string is a string representation of data separated by a delimiter(e.g. ","). A simple representation of the delimited string will look like. Delimited String Examples Sample-1-- Delimiter as ","        Value1,Value2,Value3   Sample-2-- Delimiter as "|"        Value1|Value2|Value3 If we want to represent the above set of delimited values in the form of an XML document under some root and parent tag. The representation will look like this. XML Example <root xmlns="http://test.com/sample/xml">   <Values>     <value>Value1</value>     <value>Value2</value>     <value>Value3</value>   </Values> </root> Sometimes we may need to convert values coming in delimited string to an xml document or vice versa. Since delimited string is similar to csv format. We can create
Read more

Import and Export MDS artifacts in SOA 12c

Image
Oracle SOA-MDS (Metadata Store) repository can be used to access artifacts that can be shared among various SOA composites. For example, we have one common schema for a business fault that is consumed by various applications. Instead of having a localized copy of that schema file in each SOA composite, we can have it in a centralized repository (SOA-MDS). Another benefit of using SOA-MDS is that we can change the file at runtime and need not redeploy the complete code. While developing SOA composites, we use SOA design-time repository, later these changes can be synced to the SOA servers. In this article, we will discuss 2 ways to sync the artifacts available in the SOA design-time repository and the SOA servers. Establishing the connection to SOA-MDS in Jdeveloper. Using SOA em console or Fusion Middleware control console. Moving a file between SOA composite to SOA design-time MDS repository Let's assume, we created a businessFault.xsd which wi
Read more