BEA Weblogic Integration

One of my projects late in 2008 and early in 2009 included the integration of several systems, including data transformations, orchestration, DB2 data access, Oracle data access and web services calls.
For the job, BEAs Weblogic Integration 9.2 was the tool selected.
I never worked with Weblogic Integration (WLI) before and I had to learn to use it (all by my self) in order to use it myself and to teach it to other team members.

WLI seems pretty easy to use, as any marketing documentation about it will say. What they don't say is that it does not deliver what is promissed.

I, obviously, did some tests before starting the real project integration code, and the tests started to reveal some problems that, with the help of local BEA support, I found they were just my "fault", since I was still learning WLI.
The proof of concept went well, and then, again with the help of local BEA support, we defined how the system should work. Here it is, grosso modo:

• There is an extraction process, triggered by a temporal event, that will read DB2 information.
• The BD2 information will be composed in batchs, each having n DB2 rows.
• The extraction process will call the integration process with a batch as its input.
• The integration process is triggered by a web service call.
  
• The integration process processes each batch row using the WLI transactional mechanism.
• The transactional mechanism is configured to freeze if an error occurs.
  

Please note that both the extraction and the integration processes are part of the same WLI application, they are siblings, they do know about each other existence and they do communicate.

I started to develop the processes and soon I was getting errors. I developed workarounds for the errors in order to continue to develop the application, but there was a time when I really had to request BEA local support again.
I had so many problems and so many workarounds that the hole process started to became a nightmare and WLI went from "solution" to "problem".
Has I was showing the errors to the BEA local support guy, he was totally surprised and kept saying "that has to work" to each error I was showing him.

Here's some of the major problems I found on WLI:

• XQuery transformations failed at runtime but went well on the tests performed at design time, even when using the same inputs.
  
• Transactions crashed the system. When the extraction process calls the integration process and this one has a transaction, the system crashes.
• Web service calls with transformations fails. When calling a web service, the mapping of the source data into the web service input schema failed: the application created some files but the transformation editor, with the transformation itself, failed to load.
  
• Automatic generated code breaks sometimes.
  

Some of the problems were reported to BEA support as critical problems.
I would love to post here the solutions for the problems I've found, but unfortunately, there are none... BEA just gave me some workarounds, some different from the ones I've implemented, and that's it. Instead of a solution ended up with a "workaround" implementation.
Here's the workarounds for the problems reported:

• XQuery major bug transformation: I was performing the transformations using Java code and BEA told me to change my schema to fit its product! Yep, the same schema that is shared with several web services... Yep, it seems that BEA solution was not to correct the problem but to adapt my inputs, with major impacts in other systems, to their bugs.
  
• Transactions stop crashing the system when I used JPDProxy instead of the regular process call. I told this to BEA support and, at the time, I had no other solution from the support team.
• Web service calls with transformations failure was really tricky, since there's not really a pattern for its failures. Nevertheless, I found out that:

1. Creating and empty transformation and adding its source fields afterwards sometimes it worked well.
   
2. Wrapping all the source fields on a single class it worked well most of the time.
   

• Automatic generated code breaks because no code formatting can be applied. This means that any line of code that has been automatically generated must be on a single line. Yep, if you have a web service call that has 10 parameters, which formated would make 3 lines of code breaking at column 80, you must have it on a single 214 column length line.
  

I left before BEA responded to all the problems, but my guess is that BEA support will stick by the workarounds the team has found or will propose their owns but will not solve the problem by releasing a patch that fixes the bugs.

Later, I've chatted with a colleague that has used WLI with success and he was telling me how great it is... Unfortunately I had such a bad experience with WLI that my professional opinion is: stay away from it.

./M6