Thursday, June 26, 2014

Practise BPEL Process and XSLT Programming

How did you develope your BPEL processes and XML transformation? What is the best approach for development with BEPL and XSLT in Oracle SOA Suite? Should we put most effort on BPEL processes to manipulate the data or should we put more time on XSLT to transform the data? What is a good practice for BPEL + XSLT programming?

When I ask myself these questions, I couldn't give myself an truly answer. It is really difficult to have a clear standard for these programming. But I definitely have my own 2 standards in my daily work.

  1. For business orchestration, 100% sure we should use BPEL to make it works
  2. For data manipulate or transformation, I will prefer to use XSLT to transform them
But they are not always working. As, sometimes, the XSLT may not be able to complete what you want and you may have to leverage the BEPL or even the Embeded Java. 

Recently, I worked on a project and the product of vender is using UTC time to save the datetime. But client is using local time without timezone. In the BPEL processes, I have to convert the local time to UTC time. But it is not just timezone issue and I need to handle daylight saving too. In summer, the offset is 4hrs (Toronto), but it is 5hrs in winter. I looked for a solution and tried many times, but it didn't work. At the begining, I used the current time function in XSLT to get the offset. But when I test the dates which crosses over the daylight saving change day, it will not work. What should I do?

Later, I have to leverage the power of Java. Don't laugh at me, I know it is a little of ugly to introduce the embeded Java in BEPL process. But only several lines of Java code really make the time calculation working. 

I never advocate the purity of codes, but I would insist my these 2 standards to make the code clear and maintainable and keep the intrusive codes as less as possible. Just like many years ago, when I was using Hibernate, I used it to handle CRUD and small volume of data access and never refuse to use stored procedures to handle big volume of data for efficiency.

What I believed is we should use the right tool or approach to do the right thing.

No comments: