In a recent project (developed using SOA Suite 11g) one of the requirements was to filter out certain lines of an order as these lines should not be forwarded to the business partners. In a first version we looped over all lines of the order and used a transformation activity within the loop to add each line to the response element. In case the line should not be added to the response we just ignored it.

The loop looked like this:LoopWithTransformation

The actual process contained more logic but for reasons of simplification I removed all activities that are not related to the topic of this blog post.

The XSL transformation logic was as follows:

 
 
   
     
       
     
     
     
       
     
   
 

Basically, for each iteration of the loop the old order was cloned and the current line was attached to that order (except for ignored orders, of course).

This approach worked absolutely fine, but when running the process with a large order of more than 500 lines we encountered severe performance issues. The loop“™s execution took about 250 seconds on our development environment; after we had set the log level to PRODUCTION we could reduce it to about 100 seconds, still much too long from our perspective.

So we started to use assign activities instead of the transformation. Generally, I prefer using transformations as they give you more flexibility and the maintenance of namespaces is also much easier from my perspective.

The modified loop now looks as follows:

LoopWithAssign

The first line is inserted after the header element of the order, all other lines are added to the line collection.

The same test setup as described further above now just took about 5 seconds to execute. As already mentioned the actual loop is more complex than depicted here so the run-time was now perfectly acceptable.

In a nutshell the usage of transformation activities within loops can“™t be recommended from our side. It should either be replaced by assign activities or the transformation must be placed outside of the loop. In addition to that one should generally test all processes with large records, as our developer“™s tests didn“™t reveal the issue at first as we were using rather small orders to test the basic functionality of the process only.

Alle Beiträge von alexanderdaeubler

Schreibe einen Kommentar