Open Source ERP Academy

Integrating iDempiere with External Systems

The purpose of this page is to discuss topics related to external user and API communication. iDempiere might need to communicate in the following ways:
  1. Offer data to external users
  2. Capture data from external users
  3. Offer data to an external system
  4. Capture data from an external system
How you choose to interact with an external users or systems depends on the task to be accomplished. Below are some thoughts based on common questions.

Data Export

One of the easiest ways to integrate with an external system/user is simply to export data. Here are my thoughts:
  1. You can create a dedicated iDempiere view/window that exports data the way a system prefers. Example: Alerts.
  2. You can take this concept and make it much more feature rich by creating dedicated windows to create lists for export. For example: exporting contacts for email/text communication (Mail Chimp).
    1. Create a "Notification" window
    2. Create a "Notification Line" subtab
    3. Create a Notification window => Create Lines From form with parameters to select which users to include. You can run the Create Lines From process as many times as is needed to create the desired list. Because you keep records in a dedicated window, you can know who you have spoken with, how many times and for what reasons.
    4. Once you create the desired contact list, you can simply export it in a form that is appropriate for your communication tool (mail chimp, Amazon AWS SNS service, mailing, etc...)
    5. An alternative to exporting is to provide a process that communicates directly with the external service. If successful, the process will mark the header record as "Processed".

External User Access

Anyone can login to iDempiere if you (a) give them a role, (b) give them a password and (c) give them the URL. Here are points to creating a Role for outside users:
  1. Check the Role window => Manual checkbox.
  2. Only give them access to the * window (no actual orgs).
  3. Only give them access to the needed windows (not all).
  4. Almost all windows should be read only.
  5. If you need to collect data from external users,
    1. Create a window to act as a form to submit data.
    2. Update the Window, Tab and Field window => Tab subtab => SQL Where field to be "1=2". This way external users can create data; however, they cannot edit it or see it after created. You can create a second window to "see" submitted data.

Separate Servers

You do not want to expose your primary application server to the outside world. Here are my thoughts for multiple application servers:
  1. First, make sure you separate your application server from your database server. This page walks you through the process.
  2. Second, make sure you have a dedicated application servers for the respective tasks. Here are the configuration details.
    1. WebUI for internal users
    2. WebUI/WebServices for external users
    3. Services
  3. You will place the WebUI/WebServices application server in a DMZ to help isolate external users from your internal system. You can simple shut this server down in the case of a bad situation.

Separate but Almost Equal

You can create and expose a second instance of iDempiere based on your primary server's back. Here is a discussion about creating a reporting warehouse. The backup and restore process will execute from a schedule/cron script. As the backup is restored, run SQL to remove sensitive data if desired. You can even use this instance to capture external data. You just need to migrate the data to your primary instance before it is destroyed for the next restore.

Web Services

Here is a section on web services.

Database Access

Here are my thoughts on provide direct DB access to an external user/system:
  1. This option should only be used with trusted partners. I do not recommend opening your DB to just anyone.
  2. PostgreSQL is hardened enough to be able to provide secure role-based access.
  3. You will most likely create a dedicated DB user/role with limited read and no write abilities.
  4. The only information you provide will be via dedicated database views (example: tradingpartner_orderdetail_v). This is an important concept because if forces you to create a dedicated API (the view itself).
  5. If you are only sharing data, you can create a read replica DB instance to isolate external user/system load from your core ERP System.

Other References

More Options

Please be quick to ask about options not mentioned here. There is more to be discussed...