The client is a US based Logistic and Transloading service provider, focused on providing efficient supply chain solutions.
Client’s supply chain network involved fleet management of newly built covered hopper cars, extensive railcar monitoring & consulting services, along with logistic network for car diversions and/ or storage, automated facilities for silo storage, quick railcar offloading and truck loading as well as testing of products.
Client’s Silo management business required transferring of Silo to Railcars and from Railcars to Trucks. The client was entering Silo loading and offloading transaction data using Silo Terminal Application, which in turn saved the data into Salesforce org using Salesforce Web Services consumed by a Java application hosted on Amazon EC2 Instance.
Client’s Amazon subscription was a pay-per-use model, which increased the cost burden on the client with every new transaction. Moreover, the maintenance and deployment of code for each transaction were cumbersome, posing a great challenge for the client.
To overcome these challenges, the client wanted to remove the complete Amazon layer hosting the Java web services. The client needed a direct communication channel between the Silo Terminal Application and Salesforce.com.
The objectives of the project were as listed below:
Eliminate the intermediate Java – Amazon layer
Development of a direct communication channel between Silo Terminal Application and Salesforce.com
Apex
OAuth 2.0 protocol
Eternus Solutions reviewed the business objectives and worked with the client to eliminate intermediate Java-Amazon layer and to enable the Silo Terminal application communication with Salesforce directly.
Eternus Solutions team analyzed the business logic of Amazon-Java web services. The team then redesigned all the logic using REST API web services, in order to integrate Silo Terminal application with Salesforce.OAuth 2.0 protocol was implemented to authenticate Silo Terminal Application user for providing Salesforce record access. The Silo Terminal Application user would need to authenticate himself with Salesforce via OAuth 2.0. Once authenticated, the user can insert or retrieve the data from Salesforce.
Use of REST API web services to replace the Java web services
Use of the OAuth protocol to implement secured API authorization process
Use of profiles, triggers, workflows, roles, sharing rules and security settings to manage user permissions and access rights
Development and testing on the Sandbox and moving to the Production Org
Extensive use of REST API web services, triggers, workflows, roles, profiles and security settings
Tracking of development through timesheets and weekly status calls
Development using SFDC standards and best practices
