none
Outbound Map (BTM) not Working RRS feed

  • Question

  • I am upgrading from BTS 2010 to BTS 2016.  I had a solution that allowed me to consume an incoming 999, map it to a custom schema, and send it to a SQL adapter (old style) that would execute a stored procedure to update whether or not the interchange with the matching Transaction Control Number had been accepted or rejected, and if so why.  To this day, this works just fine in the 2010 version.  When I try to migrate this solution to 2016, I am getting an odd error that the SQL adapter could not find stored procedure "ST"  Consuming an 835 using a similar process works just fine.

    My 2010 and 2016 solutions are essentially identical.  An incoming EDI message is input into a Receive Location that uses an EDI Receive Pipeline.  A subscribing SQL Send Port with a filter EDI.ST01 = 999 and an outbound map then attempts to XML transmit into the database.

    If, for debugging purposes, I instead send the output of this Send Port to a file, I get what I am expecting in the 2010 version, as shown below: 

    <?xml version="1.0"?>
    
    -<ns0:postDBUpdate xmlns:ns0="http://HMOS.BizTalk.Acknowledgements.Process997.postUpdate">
    
    <ns0:proc_837TransactionLevel_Update_997_Receipt AcknowledgementCode="A" TransSetCntrlNmbr="28704"/>
    
    </ns0:postDBUpdate>

    The incoming 999 has clearly been through the transform in the map.  I get this same output when I test the 2016 version of the map in VS2015 with the .btm test instance.

    HOWEVER, when I try this same thing in the Send Port on BTS 2016, the output I get makes it obvious that it has NOT been through the map transform.  It is the raw 999 itself, after processing by the EDI receive pipeline:

    <?xml version="1.0" encoding="UTF-8"?>
    
    -<ns0:X12_999_Root xmlns:ns0="http://schemas.microsoft.com/Edi/X12">
    
    
    -<ST>
    
    <ST01>999</ST01>
    
    <ST02>0001</ST02>
    
    <ST03>005010X231A1</ST03>
    
    </ST>
    
    
    -<ns0:AK1>
    
    <AK101>HC</AK101>
    
    <AK102>726</AK102>
    
    <AK103>005010X222A1</AK103>
    
    </ns0:AK1>
    
    
    -<ns0:TS999_2000_Loop>
    
    
    -<ns0:AK2>
    
    <AK201>837</AK201>
    
    <AK202>28704</AK202>
    
    <AK203>005010X222A1</AK203>
    
    </ns0:AK2>
    
    
    -<ns0:IK5>
    
    <IK501>A</IK501>
    
    </ns0:IK5>
    
    </ns0:TS999_2000_Loop>
    
    
    -<ns0:AK9>
    
    <AK901>A</AK901>
    
    <AK902>1</AK902>
    
    <AK903>1</AK903>
    
    <AK904>1</AK904>
    
    </ns0:AK9>
    
    
    -<SE>
    
    <SE01>6</SE01>
    
    <SE02>0001</SE02>
    
    </SE>
    
    </ns0:X12_999_Root>

    I cannot figure out why this input is failing to be transformed by the map.

    Does anyone have some suggestions for how to solve this, as it is currently preventing my upgrade?


    Thanks,

    John


    Blankfiend

    Monday, May 11, 2020 8:26 PM

Answers

All replies

  • The usual reason a map does not execute is that the MessageType of the message does not match the Source Document for the map, as that is how it identifies which map to execute so you can have multiple maps on a send port.


    • Marked as answer by John Thay Wednesday, May 13, 2020 1:40 PM
    Monday, May 11, 2020 9:25 PM
  • Thanks Colin.  Very interesting.  I have tested that in the VS project environment.  The 999 document I tested with passed input instance validation, and the map validated, and the test map yielded the correct (transformed) results cited above with the 999 instance input file.  As I understand it, the sequence with a map on an outbound send port is

    Message Box –> Outbound Map –> Send Pipeline –> Send Adapter

    What I wonder is whether the EDI Receive Pipeline on the receive location is promoting the Message Type of the 999 message properly, as this exact processing sequence works perfectly well for incoming 277CA's and 835's.

    Further investigation shows that the message coming to the Send Port outbound map from the EDI Receive Pipeline is of MessageType ==http://schemas.microsoft.com/Edi/X12#X12_999_Root.  The message type of the 999 EDI Schema available to use as a source document in the outbound map is http://schemas.microsoft.com/BizTalk/EDI/X12/2006.  When I use this latter message type in the filter of the Send Port, it fails to subscribe to the message.

    SO, I think you are right.  The question now is what to do about this.  Is it possible to change the source message type either in the properties in the mapping solution, or in a custom EDI Receive Pipeline Component so that my map will recognize the type?


    John



    • Edited by John Thay Tuesday, May 12, 2020 3:55 AM Had incorrect schema type
    Tuesday, May 12, 2020 2:55 AM
  • Adding to my last reply...

    In BTS2010, I had to build a simple EDI Receive Pipeline by adding the 999 schema to an otherwise normal recreation of an EDI Receive pipeline.  I did some checking in BTS 2010, and, using that pipeline, the incoming 999 is interpreted as messagetype http://schemas.microsoft.com/BizTalk/EDI/X12/2006 and the map works.  Using the identical pipeline, and even recreating it from scratch in VS2015, does NOT work in BTS2016.  The incoming 999 is still seen as MessageType ==http://schemas.microsoft.com/Edi/X12#X12_999_Root and the map does NOT work.

    YIKES!!!



    • Edited by John Thay Tuesday, May 12, 2020 2:50 PM
    • Marked as answer by John Thay Wednesday, May 13, 2020 1:40 PM
    • Unmarked as answer by John Thay Wednesday, May 13, 2020 1:40 PM
    Tuesday, May 12, 2020 2:49 PM
  • Thanks Colin.  Your explanation set me off in the right direction.  I found my answer in another thread at https://social.msdn.microsoft.com/Forums/en-US/49d5852d-7ede-4e31-8a6b-a0968f3fb5ad/edi-997-schema?forum=biztalkediandas2

    Here is shows how to access the X12_999_Root schema in the EDI.BaseArtifacts.dll.  I did that, replaced my source schema in my map with the one from the aforementioned dll, and all is working well now.


    Blankfiend

    • Marked as answer by John Thay Wednesday, May 13, 2020 1:40 PM
    Wednesday, May 13, 2020 1:40 PM