Order Reconciliation with backend ERP system

Hi,

Need some inputs on order reconciliation between webMethods and the backend ERP system.

What I am trying to do is design a process/interface such that there is a reconciliation tool available in webMethods which gives the status of the order i.e. whether it was successfully created in the backend system or not.

What are the recommendations or implementation ideas?

What I am planning is when the order is passed to the backend system, based on the return message (i.e error or order #) update/create an entry in a custom DB table. Have a custom dsp page reporting off of this table.

Any suggestions would be appreciated.

Are you using Monitor? If so, you can use it to monitor the transactions.

No we do not user Monitor. But how can you monitor the transactions through Monitor. Are you suggesting the backend system returns some data back to webMethods? Where will this data be stored to be retrieved by Monitor?

Hello,
It may help to tell us:

  1. your ERP product name and version.
  2. does one order in the ERP equate to one document unit comin from WM side?
  3. are you using a pub/sub setup?
  4. how do you get at the status of an order creation (SP, native API, table look-up)?
  5. what touch points on the client side need to see the result (TN Console user, web page user, whatever)?
  6. WM components you have at your deposal (TN, Monitor, Modeler, etc).

May be helpful to help you understand what you need and how someone may properly suggest you a solution. Good day.

Yemi Bedu

  1. your ERP product name and version.
    We have Baan 5.0b

  2. does one order in the ERP equate to one document unit comin from WM side?
    Yes.

  3. are you using a pub/sub setup?
    No.

  4. how do you get at the status of an order creation (SP, native API, table look-up)?

All webMethods transaction originate through TN. The way our integration works is from webMethods TN in the processing rule service after mapping to the backend strucutre, we make a socket connection to the XML/Java Adapter of the ERP system. The business object is invoked through this call, order processed and a response XML returned.

The response XML is parsed and if there was an error a notification is sent to the user for required action, TN “User Status” updated to “Error”.

This is today’s scenario. The issue with this scenario is there is no reconciliation in webMethods except for order was created in Backend or not. We would like to have data like this was the order in the backend system. Now if the backend business object returns the order what would be the best approach to store the order for easy reconciliation.

Is it recommended to store in a custom table, somewhere in native TN or not do anything and build an interface with backend system?

  1. what touch points on the client side need to see the result (TN Console user, web page user, whatever)?

This data should be available for:

  1. Reporting (through wM or another (not specific))
  2. Available such as to build a dsp page by building some services.
  1. WM components you have at your deposal (TN, Monitor, Modeler, etc).
    TN and Modeler. Monitor is available now but would not be licensed in future by our company policy statements.

Hi Nancy,

may I ask you for your wM Versions (incl. SPs and Fixes) for IS, Modeler, Monitor, TN?

This might help us with providing more specific solution suggestions.

BTW:
Monitor (or at least parts of it) is required for archiving and/or cleaning up old TN transactions.

Regards,
Holger

We are on IS 6.1 with SP1. We do not use Monitor.

We currently use the archive/document delete services through a custom wrapped service for cleaning up old TN transaction through a scheduled task and works pretty well. We have not seen a requirement for monitor to do this for us.

The approach we were designing for order reconciliation was such:
When the order is sent to the backend system through the API for processing, the API returns the Order # or the error back to webMethods. We would store this data in a custom SQL Server table (in TN DB) by using the bizdoc as the identifier. We would use a combination of stored procedure and DSP pages to access the data.

I was at Integration World this week and I got this input from there that the above approach is good with a minor change that instead of a custom table, create custom attributes in TN itself and store the data in them. This would allow transaction analysis through TN Console also using these attributes.

Hello,
I think that one possible way would be to encapsulate the returning of the (order / error) number in a new document holding the message. You can fill in extra meta data that would make it clean/clear/standard for your processing.

This ResultDocument would be posted to TN. You can have this document relate to the original source document with the wm.tn.doc:relateDocuments service. You will be relating the BizDocEnvelope containing this ResultDocument.

So all the information stays in together under one database/table (TN) that you can view with TNConsole or your custom application/webpage.

You can then also have processing rules that act on the ResultDocument by setting a specific status (Success / Order Number / Error / Queued / Pending / … / whatever) . Good day.

Yemi Bedu