none
How to process a message received via EDI & Keep Interchange intact RRS feed

Answers

  • Well0549,

    I've had an opportunity to test the overall process, and here is what I can recommend.

    1. Run an interchange file into the message box so that it suspends, and then save the suspended message.

    2. Create a schema from the suspended message using the XSD.exe tool. You will likely end up with three XSD files, one main schema and two Imported app schemas.

    3. Create your map using the main schema from step 3 and save the XSL as a file, then set the map's Custom XSL Path to use the saved file. (Alternatively, you could create a custom xslt from scratch, but this is a shortcut.)

    4. Edit the main schema created in step 2 by changing the root node type to Any. (This will cause all the links in your map to be removed, but they are not needed when using Custom XSL.) Open the schema's Imports dialog and remove the references to the two app schemas created in step 2.

    5. Exclude or delete the two app schemas from your project, build and deploy. You can apply the map in either the Receive or the Send port, depending on your needs.

    If this works for you, please let me know.


    • Marked as answer by Well0549 Friday, January 8, 2010 10:17 AM
    • Edited by R Sid Thursday, May 1, 2014 2:37 PM
    Thursday, January 7, 2010 11:20 PM

All replies

  • Well0549,

    In order to map the full interchange, the source schema has to include the service schemas (EdifactInterchangeXml and TransactionSetGroup). A shortcut is to take an instance of your full interchange message and use the XSD utility to generate a schema, but it is not very clean at all. I suppose the most proper way is to create a new schema, Include the service schemas and desired transaction set schema, and define the nodes to the appropriate types from the included schemas - takes a bit of experimenting.

    To subscribe to the message, the quickest way (without digging through the documentation) is to suspend a message, look at the promoted properties, and use the one(s) you want.

    • Edited by R Sid Thursday, May 1, 2014 2:36 PM
    Wednesday, December 23, 2009 12:42 AM
  • Thanksalot,

    This was the path i was thinking about...

    but both the schema's are already deployed in my environment.

    If I create the schema you suppose, wouldn't i get problems with double schema definitions ?
    Well0549, Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread
    Wednesday, December 23, 2009 12:35 PM
  • Yes, it could be problematic. I had started on this path with an ASC-X12 214 (shipment status message), but did not go very far because my client decided they wanted individual messages and not the full interchange.

    I am not very busy at the moment and can take another look. The shipment status is not the same as the FLOWAV landing letter, but the enveloping is similar.

    Is this for an urgent project or is it for experimenting?

    • Edited by R Sid Thursday, May 1, 2014 2:36 PM
    Wednesday, December 23, 2009 3:34 PM
  • No it's serious business
    Well0549, Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread
    Wednesday, December 30, 2009 1:44 PM
  • Well0549,

    I've had an opportunity to test the overall process, and here is what I can recommend.

    1. Run an interchange file into the message box so that it suspends, and then save the suspended message.

    2. Create a schema from the suspended message using the XSD.exe tool. You will likely end up with three XSD files, one main schema and two Imported app schemas.

    3. Create your map using the main schema from step 3 and save the XSL as a file, then set the map's Custom XSL Path to use the saved file. (Alternatively, you could create a custom xslt from scratch, but this is a shortcut.)

    4. Edit the main schema created in step 2 by changing the root node type to Any. (This will cause all the links in your map to be removed, but they are not needed when using Custom XSL.) Open the schema's Imports dialog and remove the references to the two app schemas created in step 2.

    5. Exclude or delete the two app schemas from your project, build and deploy. You can apply the map in either the Receive or the Send port, depending on your needs.

    If this works for you, please let me know.


    • Marked as answer by Well0549 Friday, January 8, 2010 10:17 AM
    • Edited by R Sid Thursday, May 1, 2014 2:37 PM
    Thursday, January 7, 2010 11:20 PM
  • thanks, maybe i try this, i will get back with the final solution to you !
    Well0549, Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread
    Friday, January 8, 2010 10:16 AM
  • Well let's try to explain my current solution to anybody who is reading this.
    The company I developed the solution for will be releasing a new EDI message version every half year.
    All the EDI messages come in via Email

    So this is the solution as it is now.

    1. Receive pipeline will unzip/unrar/ungzip any compressed attachments
    2. For the rest it will act as a passthru pipeline

    3. Orchestration Receives untyped message and does some business rule logic
    - Is the subject valid
    - Are there any smapwords in the subject
    - Is it from an unwanted sender

    4. If it is classified as a valid message, only the last attachment will be posted back to the messagebox

    5A. Another orchestration picks up the untyped message from the mesagebox
    - This orchestration will start a correlation on filename (wich is a guid by now)
    - it will send the message to a predefined file location
    - Wait for a (UNTYPED) response, or a (typed) ParserFailure coming back from the messagebox

    5B. Then I have a receive port, File location = location from step 5
    - This receive location has the EDI disassembler in it
    - It also has a special pipe component to promote the filename so I can correlate on that
    - I have Failed Message Routing set up on this RL
    - A Failed Message orchestration is listening for messages coming form this port
    - If the orch receives a message it wil create a parser failure message, promote the filename and submit it back to the messagebox
    - The failed message will trigger the correlation set up in 5A.

    5C. If the orchestration from step 5A receives a Parser failure it will post the message somewhere
    - If it was translated correct, we should be doing something to the message...
    - Submit to messagebox and have another orchestration do a map from EDI interchange to CDM.

    The beauty of this system is that the customer can deploy as many EDI schemas as they like.
    They will all fit the first 5 steps.

    The challenge is in the next step (last step from 5C). The orchestration will spit out some untyped message and I want an
    orchestration to pick it up again and perform the map to the CDM.

    So i am looking for a way to subscribe to this message and map it to CDM, but the interchange is an envelope
    and there could be several flowav message versions.......

    (The CDM will be inserted into a DB System where some checks are run. And if those checks are succesfull
    I can send an aperak)

    Is this clear to you ?

     

     


    Well0549, Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread
    Monday, January 11, 2010 3:10 PM
  • Patrick,

    It's not 100% clear, but it is coming more into focus. The issue is that your orchestration in 5C outputs an interchange message with child documents that can be in one of several FLOWAV versions not known until run-time (or at least known to change every six months or so). Once you get this interchange from orchestration 5C into the message box, you must (1) subscribe to the message with a follow-on orchestration that will (2) map the interchange document.

    This can be accomplished if you are able to create a custom XSLT translation able to recognize the important structural elements of the FLOWAV document versions and not fail on the changing versions. To do this, you need to capture a copy of the output message from orchestration 5C and build a schema in the manner I described above (this new schema basically replaces the EDIFACT batch envelope and the Any type node will accommodate changing FLOWAV versions). Promote a unique field or fields within the header of this new interchange schema that you can use as subscription criteria and use code or correlations in orchestration 5C to move these values into the context message. In your follow-on orchestration, use the promoted values from orchestration 5C as filters and use a map with the custom XSLT to map your message to CDM format.

    If you need additional assistance on any of the techniques, you should contact me directly through my web site.

    • Edited by R Sid Thursday, May 1, 2014 2:38 PM
    Monday, January 11, 2010 5:52 PM
  • Well you are very close....

    I think 5C will do a XPATH query on the first occurence of TransactionSet DocType and promote the found value on the context in a special context prop i have reserved for that purpose.

    Then I can subscribe the chained orchestration (would be 6) to subscribe on
    doctype           = EdifactInterchangeXml
    ParsedDoctype = http://schemas.microsoft.com/BizTalk/EDI/EDIFACT/2006#EFACT_002005_FLOWAV

    Then do the trick you have described. To get rid of the Envelope. Then map the "UnEnveloped" message to the CDM. Then Write the CDM to a destination DB

    If I put the orch from step 6 & the EDI schema in the same assembly, the different doc versions would be completely pluggable wich is just what I want.

    Do you see any problems with this approach ?
    ( thanks for your help so far !)
    Well0549, Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread
    Tuesday, January 12, 2010 3:16 PM
  • No problems immediately jump out at me. Let us know how it works out.


    • Edited by R Sid Thursday, May 1, 2014 2:37 PM
    Tuesday, January 12, 2010 4:08 PM
  • No problems immediately jump out at me. Let us know how it works out.

    Sid

     


    Robert 'Sid' Sidler
    Trade Talk Solutions, LLC
    Helping Trading Partners Talk Business


    It's working. Now.

    It's working as i have described.

    I am sending batched interchanges as well. with exactly the same trick. You know create an evelope schema that mimics the MS stuff. wrap that around an EDI message. And run it through the EDI pipeline. And you have your batched interchange.

    the trick was to run the message from 5c through a xmlreceive inside the orchestration pipeline (wich will promote the message type) and then send it of to the messagebox as an untyped message. The messagetype prop will stay on the mesage and stay promoted so you can subscribe on that later.

    I am glad i have got everything working just as i wanted it.

     

     

     


    Well0549, Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread
    Tuesday, August 10, 2010 6:44 AM
  • Thank you Sidler for your directions.

    I took them and used them to create an XSD (3 files like you said) schema.

    I wanted however, the 837 schema that comes with Biztalk because I know it will have the full definition not just from my one time suspended message.

    My third xsd file had the 837 in it from a inbound 837, I chopped that out from what the xsd.exe created and added in  <xs:element name="X12_00401_837"> all the way down to the code definitions from the Biztalk 837.

    I also had to add in the extra namespaces, making sure not to have duplicates.

    My project reads in an 837 - I have a sender party  set up with "Perserve Interchange - suspend Transaction sets on error"

    My orchestration matches the new schema subscription with "X12InterchangeXml"

    Way cool, I make original copies of the file to a some specified places then a map that reads how many "clm" there are. That information is emailed to those who care.

    Thanks you so much.

    Chris

     


    vb.net programmer
    Tuesday, December 7, 2010 9:32 PM