Testing loops in BPEL: Different responses depending on the iteration

After quite a long time I’ve finally manged to write another post – even though it’s just a short one. This post also centers on BPEL, especially on how to test process behavior encapsulated in while loops.

The following is based on testing BPEL processes with JDeveloper and the Oracle BPEL Test Framework. I therefore assume that we have a process that calls an external service within a while loop and shall receive different answers depending on the iteration number during test.

Call Partner Link in loop

Call Partner Link in loop

When you create a test case you need to emulate partner link calls in oder to supply the data required for your test. Unfortunately the JDeveloper GUI does not offer the possibility to define different responses for each iteration, what is quite annoying since it interferes with the developers desire to properly test the process behavior. It seems as if you have to call the real process or create some kind of simulator that returns different responses based on the input data. This violates the policy that tests should be run autonomously – that is, if you have such kind of a rule in place.

Luckily I came across the schema file that is used to validate the test cases. You may have noticed that there is no schema file attached directly to test cases, but when you enter schema violating XML you earn an error message.  Surprise, surprise, there must be an XSD hidden somewhere out there used for validation. One day I created a test case via the GUI and ended up with an invalid test case, so I searched for the schema file to understand what went wrong. To my surprise I found out that the element activityDriver posseses the attributes firstIteration and lastIteration. This led me to the conclusion that it should be possible to define different response files depending on the current iteration number. You simply duplicate an activity driver and set different values for firstIteration and lastIteration, as well as part names to define specific responses for each iteration.

The following example results in a test where PL_Reponse_1.xml is used in the first iteration, PL_Reponse_2.xml in the second and third iteration and PL_Reponse_Default.xml in all other iterations.

<activityDriver name="Invoke_PartnerLink" firstIteration="1" lastIteration="1">
 <emulate duration="PT">
 <inboundMessage>
 <part fileName="PL_Response_1.xml" name="response"/>
 </inboundMessage>
 </emulate>
 </activityDriver>
 <activityDriver name="Invoke_PartnerLink" firstIteration="2" lastIteration="3">
 <emulate duration="PT">
 <inboundMessage>
 <part fileName="PL_Response_2.xml" name="response"/>
 </inboundMessage>
 </emulate>
 </activityDriver>  
 <activityDriver name="Invoke_PartnerLink">
 <emulate duration="PT">
 <inboundMessage>
 <part fileName="PL_Response_default.xml" name="response"/>
 </inboundMessage>
 </emulate>
 </activityDriver>

Well, that’s actually all what’s behind testing with different responses in a while loop. The only drawback is the missing GUI support for this feature, but some little copy & paste, as well as adopting the data should not be a big problem.

By the way, InstaceDriver.xsd is the name of the schema file. You may want to have a look at it…

Passing parameters to ora:processXSLT

When processing XML with XSLT you can easily pass values handled as global parameters to an XSLT script. The BPEL XPath extension function processXSLT offers the same kind of functionality, even though this is not obvious at first glance.

The BPEL Process Manager Developer’s Guide describes processXSLT as “a function that returns the result of an XSLT transformation” and defines the signature as

ora:processXSLT(template,input,properties?)

where template is the name of the XSLT file, input referes to the XML strcuture on which the transformation is run and properties are “The properties as defined in the bpel.xml file”.

That’s an information , isn’t it? I’m sure you’ve immediately understood what to do. Well, I was puzzled.

Read the rest of this entry »

Posted in BPEL, SOA. 3 Comments »

When your bpel.xml seems to change by magic

Maybe you have experienced the same curiosity as I did after changing the bpel.xml file in JDeveloper and clicking “Deploy”. Somehow the file got reverted to its original state. Meaning all the changes I had made were lost, even though I had saved the file before pushing the button.

I took some research until I found that this seems to be a known issue with JDeveloper. The trick is to first close all BPEL diagram files. JDeveloper is caching the content of the bpel.xml file if any BPEL diagrams are open. When you close the BPEL files the cached memory including the bpel.xml is released and the changed file is use in the next build.