Can we use the EDI X12 850, 860 or any other document and also EDIFACT 911,95A documents as publishable documents and have a service subscribing to it, in webMethods.
The Idea is to use the EDI X12 and EDIFACT document as the canonical document and publisht he document, the subscribing side then maps the
data from the EDI document directly to the Database tables to generate the final document in legacy system.
If any body can help me, if this is good approach to use and also what all the problems we face if use the EDI standard documents as the publishable documents and also is this is actually going to work, any ideas and tips on this?
I’ve never tried it and I’ve never heard of anyone else trying it but I suppose you could make the IS doc type publishable (e.g. make EDIFFSchema.X12.V4030:T810DT publishable).
You’d create services to publish that doc type that would be called after receiving them, presumably processed via TN (although using TN certainly isn’t necessary, but a good idea).
So technically, I think it can work. The question becomes, should it be done this way?
The first question is, is there value in publishing this type of document? Certainly, the EDI format could be adopted as the canonical format (the definition of which is a document format and content that is application independent) but there are some challenges with that:
EDI formats, though they standard syntax and values and such, are often one-offs per exchange partner. That is, an 850 received from partner A can be quite different from and 850 received from partner B. Yes, they’re both purchase orders but the semantics of the contents can be very, very different.
EDI doesn’t lend itself to extensibility. Often canonical formats are “data supersets” of the applications they interact with. EDI is definitely robust and has a lot of data elements defined in each transaction set, but if you need to add custom data elements, you may end up with a less-than ideal solution by misusing or overloading existing EDI fields.
Every client that I’ve worked with that tried to adopt an existing standard as their canonical abandoned the effort fairly quickly. The idea is “we can get our canonical definitions done really quickly if we just adopt an existing standard–save us time and money.” The opposite usually ends up being the case. The standards are generally far larger and more robust than what is needed. The level of effort to work with these is not trivial and if you customize it in any way, you lose the benefit of adopting an exisiting standard.
Defining and using effective canonical formats is really, really hard. The coordination with all the stakeholders takes time, patience and a bit of luck. Using an existing standard doesn’t simplify this effort.
This leads me to the question: Are you sure you need canonical documents? If so, lacking other info about your specific situation, I’d offer that adopting EDI formats as the canonical format is to be avoided.
Some EDI documents can be huge. POs. Invoices. Ship notices. They can all get to be 100s of MB, depending on the industry. Publishing large documents such as this is generally a Bad Idea.
This leads me to the questions: What are you publishing now? If nothing, what leads you to want to use publishing? Pub/sub has its place in integration. It provides good flexibility and can encourage application decoupling. But it also introduces complexity. Managing and monitoring a system that uses pub/sub is quite different than doing the same for a non-pub/sub system. Be sure you know what you’re getting into–don’t use Broker just because it’s in the toolset.
Its not advisable to make EDI documents as publishable…Use TN component in the middle for any B2B/EDI integration which gives visibility,scalability,maintainability,tracking etc…Avoid using broker for EDI passthru’s…If you wanted to use Broker pub/sub the create canonical documents create a custom IS document with all the necessary/required fields that your business/back-end expects…Next step perform EDI mapping to Canonical doc do (pub/sub)these and send to backend and viceversa…
Thanks, for your reply, this is one of the suggestions given by one of our colleagues, the idea is that we recieve the EDI documents by TN and then we develop a processing rule which maps the inbound EDI data to the EDI document, it can be 850, 860 or anything, the service maps the data one to one, and then it publishes the document to the broker.
Our company recently acquired a new company which has a different backend system, to process the Orders, and we have our standards and canonical documents defined, and to implement the integration as quickly as possible we were asked come up with a model to do that.
The idea is instead of creating new canonical documents we will use the existing EDI document standards as the canonical documents and then publish them to the broker, then the subscribing service, extracts the data and then inserst them into database tables.
I was wondering whether it is possible to use the EDI document standards as the publishable documents and is this model going to work, my approach would be same as urs, develop canonical documents to do this, and then publish them to borker.
Any suggestions on this would be very helpful in evaluating this approach.
Thank you Reamon, your suggestions have helped us to decide on this idea.
I have one question, I am new to SAP IDOC and I gotta question, for mapping any EDI document, (PO’s POR’s, ORDERS, DELFOR) or anyother documents to IDOC, do we need to create an intermediate document (Canonical Document), or SAP has in built IDOC’s that are equivalent to these documents, i.e., can we map incoming EDI document directly to an IDOC or we should create an intermediate document to do this?
There are indeed IDoc equivlents to the EDI documents you listed.
Your question can be summarized like this:
Option 1: Build a mapping between format A and format B.
Option 2: Build a mapping between format A and format C. Build a mapping between format C and format B. Format C is the canonical format.
Option 1 is a point-to-point translation solution (but not necessarily a point-to-point communication solution).
Option 2 is a more generalized and more flexible solution, but introduces more moving parts and is more complex.
If you already have canonical formats for PO, PORs, ORDERS, etc., then choose option 2. If you don’t AND you don’t expect to need to send that data to more than just SAP then choose option 1. If multiple systems need the data, choose option 2.