Service oriented architecture is the latest and strongest entrant in the software architecture world with its benefits being realized when adopted in the right manner by organizations. FLEXCUBE BPEL process module is an SOA extension to the world’s leading Core banking solution, FLEXCUBE. FLEXCUBE BPEL process module adds workflow driven, task based solution on top of the core banking functions.
A well-respected, 44 year old bank in Taiwan catering to both Institutional and Retail banking was the first bank opting for FLEXCUBE BPEL processes module to “SOA enable” their software ecosystem. The basic requirement was to deliver a SOA business process based task driven solution for their trade finance requirements. The challenge was to matching the existing AS400 system (a 2 tier solution) capabilities using the FLEXCUBE BPEL process module which is a “n tier” Java-based solution. Performance expectations were huge and the BPEL component of the Oracle SOA suite 10g, on which the FLEXCUBE BPEL infrastructure was built on, was still in its nascent stage. Oracle BPEL component provides an Application Programming Interface (API) which is used by the BPEL infrastructure for FLEXCUBE.
FLEXCUBE BPEL module adds workflow and task driven solutions. The user interface of this module enables the user to view tasks assigned to him/her. These tasks are shown to the user and are grouped based on various attributes of the task. These groups are called queues. The queues will also display the count of tasks under them. For this bank, the number of queues was huge (as they wanted the replication of their existing system). To fetch the count, the API executes as many database queries as there are queues and the queues are viewed multiple times by a user based on his/her requirement. During user acceptance and stress testing, performance issues surfaced in this part of the API. These issues cropped up partly due to API deficiencies and partly due to inappropriate usage of the API to address the bank requirements. It was not possible, at this point in the project, to remove the dependencies on the API in the infrastructure. The problem was solved by modifying the infrastructure to avoid using the API areas having the bottlenecks without compromising the dependencies on the core API functionality. For example, one of the areas which were a bottleneck was query execution against the BPEL database as it was done using the API which was time consuming. This API deficiency was overcome by reaching the stage where the query is built by the API and then executing the query directly against the database rather than using the API.
The solutions provided met the business requirements and achieved the performance benchmarks as desired by the customer.
English
日本語
Русский