Sometime it's hard to believe one fit all solutions due to various constraints and requirements of the customers. In such cases preference goes with collaborating two or more system together to deliver consolidated feature outcome. This needs an integrationamong the application to maintain consistency, integrity and completeness of the data always.
Many applications catering various different problem statement delivers more than just one application due to is specific deliverables. It does delivers more in eco-system than working in silos. Eco-system helps achieve integrated communication and takes care of entire organization than just one aspect of application. Moreover need of any business is the consolidated analytics or insights, so eco-system are more towards delivering that automatically than man efforts to consolidate fetching individually.
These requirements arise for various reasons like,
- Organisation level common authentication mechanism
- Organisational data security and common data exchange platform
- Extending features from other application
- Connectivity and data exchange with Hardwares/Machines
- Distributed and offline application delivery.
There could be any reason to leverage technological benefits to organisational needs through this kind of integration.
Organisation level common authentication mechanism.
Organisations generally dealing with various different application catering to various organisation level problems has one common problem of maintaining the authentication and authorisation mechanism. In addition to that access to systems, mail servers and various different communication and data sharing applications. It is not user specific issue to maintain so many credentials to various different applications as well it has issue at organisation level to alter authentication, authorisation and access policies across all the application seamlessly.
So, organisation generally depends on the single sign-on or common authentication policies. In that case they expect any new application adding to their service should comply with these standards and services so as policy should go unaltered.
In view of such requirements while implementing an ERPNext we have been asked integrations with such authentication system. We took this as first level of integration long back and tried Google oAuth as first authentication mechanism to adopt with ERPNext. Client has an established setup and user accounts running with Google Business App. So, we explored on the Google Business Apps and oAuth and worked out the solution for the authentication.
Approach was to authenticate an account with ERPNext and then we used to pull in all the users to the ERPNext user account. This was a periodic mechanism where user accounts used to get sync with an ERPNext. So, we extended same authentication mechanism to log in user with Google Business App account or as an Administrator with normal mechanism.
This was the simplest aprpoach just to use current Google Business App credentials to access ERPNext application.
Now this standard feature available with ERPNext with latest release.Google Business Apps
Subsequently as Google oAuth was integrate and working we have written and extended functionality to sync in Google Calendar and Google Contacts for the user to their own accounts. With the help of the same user was free to create/add an calendar event either in Google Calendar or ERPNext calendar and all the events would sync in the end to maintain a common set of events available on both the calendars. Similarly user were able to add and manage contacts from both interfaces. Microsoft 360
Recently we have integrated Microsoft 360 based authentication mechanism for one of our client. They are having user access policy based on Microsoft 360 so same gets extended for ERPNext application authentication as well. User was being redirected to Microsoft 360 portal and then user authenticates with portal which in turn sends a data load back to ERPNext.
This validates the data loads and create a session for appropriate user back in ERPNext and redirects to Desk. LDAP/AD/ADFS
Initially we had tried hands with integration of LDAP and AD integration, but challenge with that is AD mostly maintained within an organisation and doesn't have access over internet. So, cloud based solution like ERPNext has challenges to get authenticated with an application unless it goes as on-premise implementation.
Latest we finished with an integration with ADFS+SAML mechanism. This integration was some what different than the other authentication mechanisms we had worked so far. In earlier cases services were different but authentication mechanism was similar but in case of ADFS approach was different. It took a while to understand it properly. ADFS talks in SAML format which essentially XML and receives and sends data in SAML format. So, we have integrated Python-SAML library with ERPNext. Library takes care of all service configurations and URL's required for request and a callback as well data conversion between JSON to SAML. First of all application communicates with ADFS (which is maintained with Microsoft Azure Cloud) and it generates unique authentication URL for the session. Then it communicates back with the ADFS for authentication and it returns attributed data along with callback upon authenticated.
This integration was more than authentication and carries user data maintained with platform. This way every user and it's data was maintained and managed centrally and available with application on request and with proper authentication.
Magento is old, well known and very popular eCommerce platform in the market and various eCommerce business runs using this platform. This platform has very good presence as eCommerce portal but lacks many features as ERP require to manage backend operations to support the platform. So, many organisations and individuals look for an option to support the backend and prefer to work in tandem with eCom portal to deliver what is expected as complete solution.
So, we have executed similar case studies with this integration. It is preferred to have one application as master for one type of entries and/or transactions where other should take care of rest of data and transaction. Then it shall transfer data as part of sync policy to maintain transaction integrity and data completeness. Preference is to maintain Item Master, Purchase, Inventory/Stock, Price Lists and Tax Policy with ERPNext whereas Customers, Sales Invoices, Special Price Lists, Discounts and Offers with Magento. Rest Item Master, Stock, Price List and Tax Policy sync up with Magento from ERPNext and Customers, Sales Invoice along with taxes and final amount of sale (may include discounts and offers) sync back with ERPNext from Magento.
Maintains special transactions such reconciliation which takes care of failures in between or do the transaction review and corrections if any. As well stock reconciliation adjustments etc.
Moodle is well known and very popular eLearning (MOOC) platform. This is complete in terms of eLearning platform but organisations looking to run a business model requires a strong backend to handle the business and management operations. With similar efforts, we have proposed to integrate Moodle with ERPNext. Moodle portal takes care of Courses, Students, Batches, Course Delivery, Certifications and Tracking where ERPNext strongly supports in CRM cycle, Course creation, costing, Vendor and services management, Sells Cycle, Contracts, Accounts and HRMS.
These two application works hand in hand with respect to various data exchanges and transaction validations. Like whether course delivery to be started? Whether batches to be initiated and started? Whether course completion and certification should be completed?
In this integration applications are not inter dependent on all the transactions as in case of eCommerce integration but validation of transactions and data sharing is the major part of integration and syncing.
UPS is shipping service and which deals with order shipping and delivery. To maintain an end to end transaction till delivery updates we have integrated this service with ERPNext. This is different level of integration where one system talks to other system to record the transaction in supporting system. This helps extend service in operation. UPS has SOAP and REST based API to integrate based on volume and type of shipping service required. So, once order is booked and confirmed we initiated a call with UPS with all the required details to raise the service request with UPS to schedule and deliver the order to customer. Once service is requested then used to query the service for further updates and same will updated back in the ERPNext against the delivery note and mark complete the transaction. This has helped to achieve end-to-end operations of an organisation.
There was very unique requirement as part of one of the service execution. Company was dealing with radiology labs with various products and service to support the radiology operations. Extending the services of an ERPNext, we have developed a medical ERP for all the operations of the lab to maintain patients and transactions. More to that implementation has integration of ERPNext (patients, schedules and tests data) with mediator instruments which is interlaced with various radiology lab devices. We used Mirth Connect which is cross-platform HL7 interface engine that enables bi-directional sending of HL7 messages between systems and applications over multiple transports available under the Mozilla Public License (MPL) 1.1 license. So, we run Mirth connect as service along with the applications and maintained a configuration to exchange data between ERPNext to Mirth and then Mirth to intermediate system.
This way we could transmit the data between application to systems in real time as soon patient walks-in to hospitals as per schedule. This way operator gets all the next patient to attend, tests to be executed and further information such as patient history or allergies if any. This intermediate process has helped to attain a speed and efficiency in service. As soon test gets executed it used to share the imagery to ERPNext (through proprietary application) to maintain with patient profile up to date.
We have executed this recursive integration to support various remote and offline terminal of the systems to be part of the solution. One side we have implemented full fledged ERPNext over a cloud service which has all the control and parameters to maintain and other local instances (offline) running in sync with cloud service. Local instances were managed using VBox based boxes as offline services across various remote and non (regularly) connected terminals. Process sed to start with installation of offline instance, registration with cloud service and this is to form a integration and maintain data sync policy. This way system used to run across various terminals offline but finally used to sync as per policy once a day or week with cloud to maintain the services up-to-date and data consistent.
This formed very basic platform to run the system with various areas not so well connected (offline operations) but still part of business, system and organisation with the help of regular sync and data exchange.
In this effect we have adopted with zoho reports utility which syncs the required data from ERPNext database to Zoho repository. With this configuration and sync mechanism in place with ERPNext, it syncs data from the ERPNext to Zoho reports periodically. Once data is available at Zoho Reports then it is far more capable to transform your data into various information insights easily and seamlessly.