The story of the damn doubles

This article was prepared by Dmitry Ovcharenko, the architect of the Applied Financial Systems Department of Jet Infosystems



Let there be a unification! This decision was made when designing an integration architecture that links CRM with other external systems via the bus on the Oracle Service Bus. In addition to online integration based on web services, it accepts files entering the system and calls web services on the CRM side, specifically designed for each type of incoming data.



The file contains a lot of records, and for each you need to make a separate service call on the side of CRM. File processing is performed in a loop of records. Each call to the service takes 5 seconds - this is quite a lot, but it was quite enough to fulfill the set requirements. The process of processing a web service call in CRM preliminarily checks the record for a double, then executes the required business logic and creates an entry in the database.

')

But "surprise" may occur in unforeseen moments of "tire". On industrial volumes of data in the database CRM began to appear duplicates. We found out that the source can for some reason resend a large file (immediately after it is picked up by the file proxy service and placed in the Stage folder). Moreover, the lag between calls to web services that create duplicates is so small that at the time of the second call, the data in the first one is not yet committed, and the verification on the CRM side does not have time to work.





To hell with the unification! We decided to implement a separate Java Statefull service, which stores in memory the names of files currently being processed. When a file is received, the proxy service on the OSB calls the Java service, sends it the file name and finds out if it is being processed now. At the end of the file processing (or in the case of an exception), the proxy service informs the Java service that it has finished processing the file with the given name. Accordingly, this name from the current list must be removed. Handling two files with the same name is not allowed by business requirements. Restarting the server is also not terrible, since not only the Java process will be dropped, but the file being processed, if it happens during the reboot.



In general, in Oracle SOA Suite Service Bus 11g there is no possibility to set a lock on a process with synchronization by any identifier - it is proposed to use this approach not only to restrict the launch when the file is received again, but in principle in any cases, passing to the Statefull service required identifier.



It is important that the OSB file has a top-level Catch block in order to remove the name of the file being processed from the list, even if an exception has occurred.



Service Code:

@WebService(serviceName = "TaskManager") public class TaskManager { private static HashMap<String,String> map; public TaskManager() { super(); map = new HashMap<String,String>(); } @WebMethod @WebResult(name = "Result") public String addTask(@WebParam(name = "ProcessName") String name){ String result; try{ result = map.get(name); // Try to get name from map }catch (Exception e){ // if there is no such name result = null; // we receive exception } if (result == null){ // if there is no such name map.put(name, "Is running"); // we add name result = "Task added"; } else{ result = "Task is running"; // else - inform caller } return result; } @WebMethod @WebResult(name = "Result") public String removeTask(@WebParam(name = "ProcessName") String name){ String result; try{ result = map.get(name); }catch (Exception e){ result = null; } if (result == null){ result = "There is no task"; } else{ map.remove(name); result = "Task removed"; } return result; } } 

This method is very simple, but, unfortunately, will not work in a cluster deployment option. It is also advisable to deploy it on the WebLogic OSB Managed Server, so that when rebooting, both OSB processing and the list of current processes are reset. If OSB servers are in a cluster, the service must be deployed on a separate Managed server, and this will have to be remembered when rebooting.



Finally. With this protection against repeated processing, the solution worked for more than a year, but it was replaced by a new loading mechanism. It is implemented on Oracle SOA Suite, and the processing of records in it is performed in parallel. But this topic will open another article.



We welcome your constructive comments.