What’s so special about integration to SAP?

I saw a short news article [link no longer exists] that Microsoft’s Dynamics AX (the old Axapta) could now provide integration of documents between AX and SAP (the Microsoft press release is here). My initial thought was “what’s so special about that”, until it dawned on me that some people think SAP integration requires something magical. Granted, SAP is not the easiest application to work with, but it does have integration hooks – Netweaver being one.

If you are not sure why SAP integration is needed, the reason is that many large national and mega international corporates run SAP at the head office or for large divisions, but they don’t necessarily run SAP everywhere. There are large multi-national companies which uses SAP in their main offices, but the dozens of smaller divisions don’t run SAP, they use SYSPRO. Why? Because SAP is so complex and expensive it makes no business sense for a smaller organisation to use it, but SYSPRO provides all the functionality they need (for distribution and manufacturing) at a much lower cost and far less complexity. Analyst R ‘Ray’ Wang has discussed in more the ERP needs of small and medium businesses (SMBs) and when companies should have a two-tier ERP strategy.

Microsoft will try to sell you their Biztalk product to help the process. However, Biztalk is costly and adds another layer of technological complexity to the integration issue. If you run SYSPRO you don’t need Biztalk for SAP integration.

SYSPRO solved the problem a long time ago when it introduced its e.net integration software and a feature called Document Flow Manager (DFM). SYSPRO e.net solutions (the proper name of the product) is a set of components that enables access to SYSPRO business logic and data without using the SYSPRO client interface; it was one of the first applications to take advantage of Microsoft .NET Framework for interoperability and application integration. The DFM module consists of a group of services that:

  • poll a data location (ie, folder) looking for files (documents), or for incoming email looking for particular attachments,
  • compare documents against specified ‘contracts’ for a match,
  • places the matched documents in a message queue,
  • processes the message queue and applies an appropriate SYSPRO business object to process the document and return a result

The contracts can be configured to specify file types that must be located and which SYSPRO e.net business objects must operate on the files.

Incoming documents do not need to be in XML format. A contract can specify pre-processing using XSLT (Extensible Stylesheet Language Transformations), an XML-based language used for the transformation of documents into XML documents. The same process can be applied in reverse to ongoing documents.

You will need .Net Framework and a few other bits of Microsoft software (such as MS Message Queue), but they are essentially “free features” available in Windows.

While the skilled work is in setting up the XSLT transform and configuring the contracts, the important work is getting suppliers or customers to agree to using electronic document processing and a standard for the documents. Ten years ago, some vendors started talking about inter-company transaction processing using integration software. Now the reality is here and the functionality is available. Remember, SAP integration is not difficult if you have the right technology and, of course, the budget and commitment to do it.

Are you considering a more cost-effective ERP for parts of your organisation but worrying how to link to the head office SAP system? Have you been told you need Biztalk, or some other costly specialised software, to allow you to transact and operate electronically with partners or larger divisions? Have you looked at SYSPRO? I would be interested to hear your comments.


4 thoughts on “What’s so special about integration to SAP?

  1. Simon,

    Thanks for the clear exposition. I don’t know Syspro’s integration offerings, per se, but your basic points (it isn’t necessarily complicated, a simple integration framework may be all that’s needed) are clearly right.

    I do, however, have a couple of questions. The most typical “SAP integration” announced by other vendors takes GL transactions and pushed them up to and into SAP, usually in the form of journal entries. Do the Syspro capabilities you’re describing do that? It’s not clear to me from your exposition because I’m not sure what a “document” is.

    Second, I would like to caution anybody considering SAP integration of any kind about two issues that turn out to be crucial. The first is the fact that there may be a “semantic mismatch” between the SME system and SAP and that integrations need to take this into account. A “semantic mismatch” occurs, for instance, when you code a Department/Geography as DDGG in your chart of accounts, but SAP codes the department and geography in two different fields.) You’d think that fancier integration packages (Biztalk) deal with semantic mismatches better than not-so-fancy packages. Not the case. For customers, the only thing you can really do before you buy an “SAP integration” is make sure that the package deals with your mismatches.

    The second is that there are often timing issues with some integrations. You need to make sure that an integration happens or works before some other event happens. Here, too, expense or fanciness of package is usually meaningless. If you have to have an integration that involves some sort of coordination between two systems, you just have to make SURE it’s supported.

    • Thanks for the comment.
      1. A DFM document is made up of a data and a definition component. The data can be any type or an image, the definition is what is matched to a contract which specifies the sequence of operations to be performed on the data. So, the data could be GL transactions in a data format or as XML, which could then be transferred to another system like SAP.
      2. Where you need to handle a “semantic mismatch”, the contract would specify how to convert the data, whether via an XSL transform or a program (written in VBScript, C#, etc).
      3. The timining issue would require planning on how to queue and place the documents.

  2. Just a quick note to give support for your observations about Syspro.

    “SYSPRO provides all the functionality they need (for distribution and manufacturing) at a much lower cost and far less complexity”

    I appreciate your upfront and candid comments.

    Thank you.


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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s