Ways of integrating Vault with ERP

2015-08-31_09-58-26

powerGate is become quite popular and more ERP system are now connected to Vault via powerGate. There are basically three ways for connecting Vault with an ERP system via powerGate:

  • Online via native ERP API (SAP, Navision, proAlpha, myfactory, etc.)
  • Online via database (Sage, etc.)
  • Offline via file transfer (Abas, etc.)

We usually prefer doing online integrations, as the user has immediate feedback whether the transfer did work or not, and there is less need for having data redundant in both systems. However, where an online integration is not possible or nor welcome, the good old fashion file transfer is also OK.

A few weeks ago I’ve wrote about the integration we made with Sage, online via database. Today I’d like to tell you about the integration with ABAS. The usual way to exchange data with ABAS is via XML files. ABAS provides scripts for importing and exporting XML files. Therefore, powerGate will in this case read and write XML from and to a folder.

We wrote a small powerGate plugin which reads and writes XML files from and to an exchange folder. The usual entities are items, BOMs and project data.

As powerGate is a push/pull system, so it reads data from the ERP when needed and writes data into the ERP when necessary, we will cache the XML data into a little database. When a write (create/update) operation from Vault goes to ERP, in this case ABAS, the XML files are immediately written in the according folder, and additionally, the data is also stored into a database. When information from the ERP system are requested by Vault, new XML data from the ERP will be processed into our database, and the data is then read from the database.

The result is a sort of faked “online” integration. We can read ERP data whenever we want, and we can write data whenever is needed. The XML files produced by Vault (on writing) in the according folder can be processed by the ERP system when appropriate. The XML files produced by the ERP are processed whenever a read operation is performed in Vault.

You may argue that even in this way we have a redundancy. Yes, sort of, but it’s in an interim database which we can access and change whenever we like. If all the information would be stored in Vault, then updating ERP information would become more complex, as files or items could be released, checked out, and so on. By having the ERP data in a separate database, the update of the ERP information can happen right away, independently from the permission situation in Vault.

In our case, we use SQLite for the database. It has the advantage that no backend is needed. The SQLite database is just a bunch of files in a folder, so it’s super easy to setup and maintain, and it’s still fast enough and the size limit is at 35 TB. There are several editors that allows reading and editing data with SQLite, so in case there is a need to check or clean up the database, it’s straight forward. One editor, our preferred, is LINQPad.

There are surely other ways of doing such integration. For instance, by using a full SQL Server, or relinquish the SQL database at all. If you have other preferences, feel free to implement powerGate in other ways. This is the beauty of powerGate. You can write your own server plugin and expose the needed services to Vault for further consumption.

This entry was posted in powerGate. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s