FizzBuzz

Today I stumbled into http://codingdojo.org/cgi-bin/wiki.pl?KataFizzBuzz and decided to implement the kata as a little TDD finger exercise. Interestingly I learned that FizzBuzz is sometimes used in job interviews to validate a candidate’s ability to code. To my suprise I also learned that a lot of programmers seem to fail this test.

The FizzBuzz problem can shortly be described as:

Any number divisible by three is replaced by the word Fizz and any number divisible by five by the word Buzz. Numbers divisible by both become FizzBuzz. All other numbers remain as they are.

The task at hand is to “write a program that prints the numbers from 1 to 100 by applying the above rules”.

Read the rest of this entry »

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.

Testing your service with the BPEL console

Using default XML input

Have you ever tested a BPEL process through the BPEL console and had to replace the given XML input data with your actual data over and over again? After a while you can really become a copy&paste maniac. It was quite a relief when I found out that you can easily define a default input for your process test.

Read the rest of this entry »

WSDL – A quick walk-through

When working with webservices there is hardly a way to get arround WSDL, the Web Service Description Language. Still a lot of developers tend to think that they don’t need to know the interna, because tools like java2wsdl generate the WSDL file for them. So why bother with the details? Well, as long as you code first this might be true in parts, but the moment you have to hit a different development path, namely contract-first, things change. Now you have to create the WSDL file and respective XML schema first. Therefore it can’t be wrong to know how the WSDL clock ticks.

We will concentate on the WSDL 1.1 revision, even though version 2.0 is a W3C recommendation since March 2006 (but not wide spread one). After a short overview we will walk through the WSDL components by example. Please note, that you need to have a basic understanding of XML and XML schema for our walk.

Read the rest of this entry »

Posted in SOA. Tags: , , . 10 Comments »

Send the standard windows editor to the happy hunting grounds

Here we go again with the next little helper from my private tool box.

Are you looking for a neat Notepad replacement? Maybe you would like to try Notepad++. It’s freely available at http://notepad-plus.sourceforge.net/uk/site.htm in a lot of languages.

Actually it’s much more than a simple replacement of the standard windows editor, because of all the features. Take a closer look at the feature list below and you’ll notice that MacGyver could name it his favorite Swiss Army Knife. Yes, commercial editors like UltraEdit have a lot more to offer, but do you need all the stuff if all you want is a small and simple text editor – even though I believe Notepad++ is quite a sophisticated exemplar?

Read the rest of this entry »