By Mitul Patel
Imagine you work for a large non-profit organization. And, you are responsible for maintaining the critical donations and payment processing program for the organization. You have signed up for a lockbox and caging service from a reputed vendor. Payments are processed daily. A payment batch file is generated and sent to a FTP server. Your AS/400 system reads the file and processes it. Donations comes from your websites as well. All related information about donations end up in your AS/400 system.
For number of smart reasons you have signed up for Salesforce. Modernization of your business processes is one of them. Because your AS/400 system handles so much of your business, you are not yet ready to let it go. You want to integrate your AS/400 system with salesforce.
Lets take another scenario – a financial institution. Like many financial institutions, they sell financial products. This firm has been using AS/400 to store policy related information. The financial Institution now has decided to use Salesforce platform to service their customers. Customer representatives need to view information residing in AS/400. Not only that; any changes they make to that data in Salesforce needs to be sent back to the AS/400.
AS/400, now branded as ‘System i’, has been a great success story for IBM. Introduced about a quarter century back, it is used in almost all the industry sectors. The operating system on the AS/400, originally called as OS/400, has undergone name changes to i5/OS to IBM i . Applications for the AS/400 can be developed using RPG or Java. AS/400 applications mostly use DB2 as preferred database. VSAM and COBOL copybooks are other methods for data access.
Salesforce Integration scenarios like the above are typically accomplished using middlewares. A middleware abstracts the complexities of underlying systems, making integration simpler. They support tasks such as managing connections, translation of message formats and lower level network protocol handling. Middlewares support several network protocols – HTTP, SOAP, FTP, SMTP etc. And, they have adapters to communicate to databases, filesystems and applications. Applications can leverage middleware to expose interfaces. Other systems can then communicate to the application via these interfaces.
Diagram: Integration between AS/400 and Salesforce
To connect to AS/400 systems, several middlewares (e.g. webMethods and Tibco) have created AS/400 adapters. Wider choices of middlewares – Cast Iron, Boomi, Mulesoft, Informatica, Jitterbit, OSB and others are available, if the business use-cases allow connecting directly to the application database (typically DB2). Most Salesforce integrations prefer the direct database connection method. If direct access to database is not allowed, spooled files or output reports can also be used.
For the real time Salesforce integration, there can also be a business use-case to invoke CICS and COBOL programs. Oracle Tuxedo, Software AG EntireX and similar programs can be used for such use cases. Apache has open source programs to run service layer on AS/400. These can be used to expose web services for AS/400 applications . Middlewares can then call these web services in real time.
Almost all the middlewares on the market support Salesforce. They provide simple and configuration based setup for operations on Salesforce objects. Integration to Salesforce could be real-time using SOAP or REST services as well as batch using bulk operations. While designing the integration with Salesforce, governance limits should be taken into account. These are the limits on how often requests are made, how many requests are made and what is the size of payload.
At Appirio, we have successfully integrated AS/400 with Salesforce in several different scenarios. Salesforce integration is often an important part of a business modernization strategy. So if you are not yet ready to replace that trusty AS/400, but want to integrate with the power of the Salesforce platform, there are a lot of great options to pursue.