This project is read-only.

Inbound guidance

Oct 22, 2010 at 3:18 PM

I had a look at the PDF and it's all outbound EDI, are you going to cover inbound EDI ?

May 26, 2011 at 10:09 PM

sorry for the horribly late response, my e-mail must have eaten the notification and I simply haven't seen your post.

So, inbound scenarios.  They are actually pretty easy compared to the outbound.  I have demonstrated inbound edi landing on an itinerary, getting mapped, etc.  What in particular are you looking for?

Reason I am back on the site, btw, is that I am getting ready to update this to 2010.  One of the inbound scenarios I want to add is fix and resubmit.  I have a brute force demo working, however with EDI you need something a little more robust.  Reason is that, if you throw an error before the EDI has been translated to XML, you can fix the EDI, resubmit, and your context properties are all good to go.  However, if you throw an error after the EDI has been translated to XML and you use the ESB fix and resubmit funtionality, you loose all the context on your message so nothing gets routed.

The ESB Exception management framework captures all the context, all I need to do is pull it from the exception database and add it back on the message.  ideally I would like to let the person resubmitting the message to choose which context properties are still valid and even modify the data.

All this should be surfaced in sharepoint so an EDI admin can manage the fix and resubmit.

I have worked through the architecture and have a pretty good design, I just haven't had the time to make it happen.

Again, please share the specific scenarios you are looking for and I will work to incorporate them or describe how they could be implemented today.