Sometimes it is hard to believe one fits all solutions due to various constraints and requirements of the
customers. In such cases, preference goes with collaborating two or more systems together to deliver
consolidated feature outcomes. This needs an integration among the application to maintain
consistency, integrity and completeness of the data always.
Many applications catering to various different problem statement delivers more than just one
application due to is specific deliverables. It does deliver more in the eco-system than working in silos.
Eco-system helps achieve integrated communication and takes care of the entire organization than just
one aspect of the application. Moreover need for any business is the consolidated analytics or insights,
so the eco-system is 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 Hardware/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 there 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.
Google oAuth
Approach was to authenticate an account with ERPNext and than 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 there 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 than 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 onpremise 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. Than 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
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. Than it shall tractor 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
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
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 than 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.
Mirth
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 than Mirth to intermediate
system.
This way we could transmit the data between application to systems in real time as soon patient walksin 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.
ERPNext
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.
Zoho Reports
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 than it is far
more capable to transform your data into various information insights easily and seamlessly.