Ошибка Logic Apps: структурная ошибка в / перед первой функциональной группой

Я читаю X12 850 из очереди Azure и пытаюсь получить его XML-представление, декодированное Logic Apps. Вот образец документа EDI, который я использую:

ISA*00*          *00*          *12*TEST123ZZZ     *12*ZZZ123TEST     *171010*0705*U*00401*000032485*0*P*>~
GS*PO*TEST123ZZZ*ZZZ123TEST*20171010*070547*32485*X*004010~
ST*850*32485~
BEG*00*SA*Z-5000**20171010~
REF*PG*LLL~
DTM*002*20171113~
N1*ST*SUPERLATIVE AUTO PARTS INC.*92*4500~
N3*5555 33 MILE RD.~
N4*ARMADA*MI*48005~
PO1*1*10*EA*2.27**BP*P2224*VP*L033~
PO1*2*10*EA*5.53**BP*P5544*VP*L059~
PO1*3*10*EA*4.11**BP*P1237*VP*L020~
PO1*4*20*EA*16.3**BP*P0999*VP*L006~
CTT*4*50~
SE*13*32485~
GE*1*32485~
IEA*1*000032485~

Вне декодирования я ничего не получаю в хороших сообщениях, вместо этого все в плохих сообщениях. Мне кажется, что мое Соглашение подбирается и используется (единственное соглашение, которое я создал), но я не понимаю, как реагировать на исключение "Обмен с идентификатором 000032485, с идентификатором отправителя 'TEST123ZZZ ', идентификатором получателя 'ZZZ123TEST ' имела структурную ошибку в / до первой функциональной группы »

"body": {
    "interchangeControlNumber": "000032485",
    "groupControlNumbers": [],
    "goodMessages": [],
    "badMessages": [
        {
            "interchangeEnvelope": {
                "ISA_Segment": "ISA*00*          *00*          *12*TEST123ZZZ     *12*ZZZ123TEST     *171010*0705*U*00401*000032485*0*P*>~\r\n",
                "isA05": "12",
                "isA06": "TEST123ZZZ     ",
                "isA07": "12",
                "isA08": "ZZZ123TEST     ",
                "isA09": "171010",
                "isA10": "0705",
                "isA11": "U",
                "isA12": "00401",
                "isA13": "000032485",
                "isA14": "0",
                "isA15": "P"
            },
            "technicalAckExpected": false,
            "functionalAckExpected": false,
            "exception": "The interchange with id '000032485', with sender id TEST123ZZZ      , receiver id ZZZ123TEST       had structural error in/before the first functional group",
            "componentSeparator": 62,
            "dataElementSeparator": 42,
            "interchangeControlNumber": "000032485",
            "payload": "77u/R1MgKiBQTyAqIFRFU1QxMjNaWlogKiBaWloxMjNURVNUICogMjAxNzEwMTAgKiAwNzA1NDcgKiAzMjQ4NSAqIFggKiAwMDQwMTB+DQpTVCAqIDg1MCAqIDMyNDg1fg0KQkVHICogMDAgKiBTQSAqIFogLSA1MDAwICogKjIwMTcxMDEwfg0KUkVGICogUEcgKiBMTEx+DQpEVE0gKiAwMDIgKiAyMDE3MTExM34NCk4xICogU1QgKiBTVVBFUkxBVElWRSBBVVRPIFBBUlRTIElOQy4qIDkyICogNDUwMH4NCk4zICogNTU1NSAzMyBNSUxFIFJELn4NCk40ICogQVJNQURBICogTUkgKiA0ODAwNX4NClBPMSAqIDEgKiAxMCAqIEVBICogMi4yNyAqICpCUCAqIFAyMjI0ICogVlAgKiBMMDMzfg0KUE8xICogMiAqIDEwICogRUEgKiA1LjUzICogKkJQICogUDU1NDQgKiBWUCAqIEwwNTl+DQpQTzEgKiAzICogMTAgKiBFQSAqIDQuMTEgKiAqQlAgKiBQMTIzNyAqIFZQICogTDAyMH4NClBPMSAqIDQgKiAyMCAqIEVBICogMTYuMyAqICpCUCAqIFAwOTk5ICogVlAgKiBMMDA2fg0KQ1RUICogNCAqIDUwfg0KU0UgKiAxMyAqIDMyNDg1fg0KR0UgKiAxICogMzI0ODV+DQpJRUEgKiAxICogMDAwMDMyNDg1fg==",
            "replacementCharacter": 0,
            "segmentTerminator": 126,
            "segmentTerminatorSuffix": "CRLF",
            "agreementName": "X12-TEST123ZZZ-ZZZ123TEST",
            "guestPartnerName": "Test-Partner",
            "hostPartnerName": "Plex-As-Host",
            "ReceiverIdentifier": "ZZZ123TEST",
            "receiverQualifier": "12",
            "SenderIdentifier": "TEST123ZZZ",
            "senderQualifier": "12"
        }
    ],
    "generatedAcks": [],
    "receivedAcks": [],
    "agreementName": "X12-TEST123ZZZ-ZZZ123TEST",
    "guestPartnerName": "Test-Partner",
    "hostPartnerName": "Plex-As-Host",
    "ReceiverIdentifier": "ZZZ123TEST",
    "receiverQualifier": "12",
    "SenderIdentifier": "TEST123ZZZ",
    "senderQualifier": "12"
}

}

Мои коллеги по EDI говорят мне, что «ISA02 должен состоять из 10 пробелов. Общая длина сегмента ISA должна составлять 106 символов». Итак, я думаю, что у меня неправильно настроено Соглашение для ISA2. Следует ли что-то указывать в поле ISA2 в Соглашении? Я попробовал десять пробелов, которые потребовались, но все равно получаю ту же ошибку: «Обмен с идентификатором 000032485, с идентификатором отправителя TEST123ZZZ, идентификатором получателя ZZZ123TEST имел структурную ошибку в / до первой функциональной группы»

Пользовательский интерфейс соглашения


azure-logic-apps edi x12
person Tom Schulte    schedule 05.12.2017    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Ваш ISA-сегмент выглядит нормально, структурно. ISA02 / 04 чаще всего остается пустым.

Но, глядя на другой контент, есть ли место после всех ~? Это вызовет проблемы. Только CR и / или LF разрешены в качестве суффексов.

person Johns-305    schedule 06.12.2017
comment
Спасибо, Джонс. Нет, после тильд нет пробелов. Я также проверил, расшифровав полезную нагрузку в ответе действия и проделав то же самое с необработанным вводом действия, поэтому я знаю, что на этом пути не появилось никаких пробелов. Хотя у меня нет глубоких знаний в области EDI, здесь он используется уже несколько десятилетий, поэтому я уверен в образце, который мне дали мои коллеги по EDI. Я уверен, что это каким-то образом связано с конфигурацией или настройкой Logic Apps. Или, может быть, более конкретно учетная запись интеграции. - person Tom Schulte; 06.12.2017
comment
Где находятся разделители элементов в GS выше: GSPOTEST123ZZZ ZZZ123TEST * 20171010 * 070547 * 32485 * X * 004010 ~ это должно быть GS PO * ..... - person Andrew; 07.12.2017
comment
SO видит символ '*' как средство форматирования Ital. Посмотрите ПО. - person Johns-305; 07.12.2017
comment
Ах, в этом есть смысл. Я бы просмотрел весь документ в HEX и убедился, что после тильды нет ничего. Это выглядит так, но это также может быть форматирование SO. - person Andrew; 07.12.2017

arrow_upward
0
arrow_downward

Кажется, у некоторых валидаторов EDI есть проблемы с работой с циклом PO1, не имеющим дочерних элементов.

Следующее сообщение проходит проверку, имея MSG сегментов в качестве дочерних для PO1:

ISA*00*          *00*          *12*TEST123ZZZ     *12*ZZZ123TEST     *171010*0705*U*00401*000032485*0*P*>~
GS*PO*TEST123ZZZ*ZZZ123TEST*20171010*070547*32485*X*004010~
ST*850*32485~
BEG*00*SA*Z-5000**20171010~
REF*PG*LLL~
DTM*002*20171113~
N1*ST*SUPERLATIVE AUTO PARTS INC.*92*4500~
N3*5555 33 MILE RD.~
N4*ARMADA*MI*48005~
PO1*1*10*EA*2.27**BP*P2224*VP*L033~
MSG*LINE ITEM 1~
PO1*2*10*EA*5.53**BP*P5544*VP*L059~
MSG*LINE ITEM 2~
PO1*3*10*EA*4.11**BP*P1237*VP*L020~
MSG*LINE ITEM 3~
PO1*4*20*EA*16.3**BP*P0999*VP*L006~
MSG*LINE ITEM 4~
CTT*4*50~
SE*17*32485~
GE*1*32485~
IEA*1*000032485~

Я протестировал это с помощью онлайн-валидатора EDI: http://edivalidation.com/valid.html

person Stavr00    schedule 12.12.2017
comment
Этот валидатор был бы неправильным. Нет проблем с сегментами PO1, не имеющими дочерних сегментов. Держу пари, что в данных есть тильда и CR / LF. Некоторые валидаторы не обращают внимания на это, другие будут рассматривать это как терминаторы трех сегментов. - person Andrew; 12.12.2017

arrow_upward
0
arrow_downward

На самом деле мне нужно было решить две проблемы. Оба были связаны с консольным приложением, которое я написал для отправки сообщения в очередь Azure, прочитанного приложением логики. Вставка документа EDI в качестве значения в строковую переменную привела к появлению пробелов вокруг звездочек. Это была первая проблема. Затем, поместив BrokeredMessage в очередь, мне пришлось использовать явный поток MemoryStream, чтобы убедиться, что содержимое никоим образом не было изменено (добавлялись дополнительные символы), как объясняется здесь http://www.bfcamara.com/post/84113031238/send-a-message-to-an-azure-service-bus-queue-with

После того, как я исправил обе проблемы (и настроил свою учетную запись интеграции для сохранения деталей обмена при декодировании), я успешно увидел X12, декодированный в XML с помощью Logic Apps.

person Tom Schulte    schedule 12.12.2017