You are on page 1of 4

What are the timescales you are working to ? 3-6 months Who is the end user ?

We specialize on the delivery channels (Internet Banking). As part of our product revamping strategy, we are planning to push all third party integrations on to an ESB / Integration Server. Our clients are mostly banks across India, MEA & Africa. What has been your historic level of engagement with your client ? It depends on the acquistion. It typically varies from as short as 6 months to almost a decade. Some insight into the process for acquisition with your client ? Demo / PoC etc ? A POC / Demo might be required to convince the bank on our solution's capability in addressing the concerns such as scalability, high availability and extendability. Some background info to the requirement ? Currently, there are 30+ batch jobs that are being executed as stand alone java programs. These programs threaten the scalability of the application. Typically, these batch jobs do the following: The file upload batch job Poll the database for new records. These database tables have a blob column where the data to be processed (typcially payment instructions in the form of flat files csv, fixed length etc) are saved as blob objects. Once, records are available, the data is extracted from the blob columns. Parsed, and extracted to another set of tables for authorization. Almost, the file format differs from one corporate to another with regard to payment instructions and the format in which they expect the advice files back from our system. Once, authorized from the Web user interface, another batch job picks the authorized records and checks if it requires second authorization or verification. If so, it updates the status of those records accordingly. If not, request objects are prepared for the payment instructions and pushed to middleware either via MQ / Web Services / Sockets for further processing at the bank's core banking system. In case of Websphere MQ as the middleware, there are a couple of MQ triggers that receive the response from the core banking system and update our payment instruction tables with the status. There are another set of batch jobs that scan for responses from the bank's core system and once, any new responses are available, they start generating the advice files to be sent to the client / made available to be viewed from the web interface. The batch jobs, do not use database connection pooling / MQ Connection pooling. The batch jobs are not capable of parallel processing, since, they do database polling to figure out if new records have come and if so, they do not lock the available records. This can result in the same set of records being processed by multiple instances of the batch jobs. The batch jobs heavily use local file system for generating and storing advices. Some of the batch jobs are not multi threaded. Managing and monitoring these batch jobs have become difficult.

What level of individual are you engaged with ? IT and Business Managers Does your client have budget ? Yes What does your clients environment look like ? Apps, processes, infrastructure ? Though it varies from client to client, here is a typical environment Application Servers: JBoss, WebSphere, Weblogic (on windows, linux, aix, hp-ux etc) Database Servers : Oracle Middleware : TIBCO, Websphere MQ , No middleware etc Why do they need ESB ? We need to justify why they need an ESB and how it can help them in achieving scalability, high availability and reliability for our application. What current middleware do they have ? It varies from client to client. As indicated earlier, couple of middlewares like Websphere MQ, TIBCO etc. Our understanding of some of Talend ESB's capabilities: 1. Talend supports parsing and extraction of data from text files and update them to a database. 2. Integration with messaging systems like WebSphere MQ. 3. Support for camel routes with support for invoking talend jobs as part of the camel route. 4. Monitoring the services 5. Ease of deployment. 6. Clustering capabilities (distributed processing & load balancing) 7. Service Discovery / service location transparency (using zookeeper) 8. Connectivity to Databases (oracle in specific) 9. Email Integration 10. PDF / Document generation Our approach: Each batch job be implemented as a service in Talend ESB. The web interface would invoke the service by discovering them using zookeeper servers. Upon invocation of service, the service would parse the file and extract the contents to a set of database tables. The user once authorises the payment instruction, can invoke another service in talend which would generate the xml messages and push it on MQ Queues. Wait for responses and update the status in the database. At the same time, it can trigger another set

of services that can do the generation of advices and send them to the designated mail receipients. Proposed architecture diagram.

Client's concerns: 1. Will ESB be an over kill for this? 2. Instead of subscription based ESB implementation, is there a license based implementation? 3. Hardware and operating systems that the ESB can run on? Especially AIX? 4. Other than ESB, any other alternative approaches explored? We did find something like Compute Grid from Websphere and Spring Batch having batch processing capabilities. However, they address only a specific portion of the requirement and not an end-to-end solution.

You might also like