none
"Envelope functionality not supported" Error in pipeline processing RRS feed

  • Question

  • Starting to figuring out EDIFACT messages processing.

    This is what i've done.

    Imported into my project the EFACT_D96B_CUSDEC.xsd as included in R2 beta2
    Created a very simple orchestration, that has a file receive port with an EDI pipeline (a pipeline with an EDI disassembler)

    As soon as i put a file in the folder, the message is immediately suspended (aparently on the pipeline), i get the following error on the event viewer.

    I know the message is a valide CUSDEC message (some parts of the error message have been cleansed).

    Error encountered during parsing. The Edifact interchange with id '070301090801', with sender id 'XXXXXXX', receiver id 'YYYYYY' had the following errors:

    Error: 1 (Miscellaneous error)
        47: Envelope functionality not supported

    Error: 2 (Field level error)
        SegmentID: UNB
        Position in TS: 1
        Data Element ID: UNB6.1
        Position in Segment: 7
        Position in Field: 1
        Data Value:        
        37: Invalid character(s) found in data element

    Error: 3 (Field level error)
        SegmentID: UNB
        Position in TS: 1
        Data Element ID: UNB8
        Position in Segment: 8
        Data Value: pdx45549.b01
        39: Data element too long

    Error: 4 (Field level error)
        SegmentID: UNB
        Position in TS: 1
        Data Element ID: UNB11
        Position in Segment: 11
        Data Value: PT999999999
        37: Invalid character(s) found in data element

    Error: 5 (Field level error)
        SegmentID: UNB
        Position in TS: 1
        Data Element ID:
        Position in Segment: 6
        Data Value:
        12: Invalid value in data element
    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Any clues?

    Thanks.
    Saturday, April 28, 2007 6:28 PM

Answers

  • No mistake on the transcription, the UNC is as quoted (minus the sanitization).

    You are quite right. Been reading the specification it this violates the specificatio. Been checking all the messages that have flowed the production (the system R2 is going to replace) and all messages of this type are like these. Very strane, will have to check with my client. This system is in production for quite a few years.

    I guess this leads me with the next (related) question. How can i generate the return message with the error?

    Should i subscribe for suspended messages on the receiving pipeline? or is there a better way to acommodate this?

    Thanks for your help
    Tuesday, May 1, 2007 2:30 AM

All replies

  • The CUSDEC payload might be valid but the UNB envelope segment is invalid. E.g. UNB8 is a 1 digit field that indicates Processing Priority (e.g. 1) and the instance has pdx45549.b01 as value.

     

    Could you paste the UNB segment data?

    Monday, April 30, 2007 7:06 PM
  • Here it goes.

     

    UNB+UNOC:3+XXXXXXXXXXXXX:14+WWWWWWWWWWWWW:14+QQQQQQ:0908+070301090801+       +AAAAAA+pdx45549.b01+++PTBBBBBBBBB'

     

    I've sanitized the data, but keep the field's lenghts. If you need the unsanitized data i would be more confortable emailing it, directly to you.

     

    Is it possible, to get trace events from the EDI pipeline? this would probably help diagnose things.

     

    Thanks.

    Monday, April 30, 2007 9:59 PM
  •  

    UNB6 (receipient reference password) is spaces which is not allowed. UNB8(processing priority) should be a number like 1. Are you sure that UNB6 is spaces in your case? Maybe UNB6 is AAAAAA, UNB7 is pdx45549.b01 and UNB8 is empty.

     

    You can use btstrace to get trace events from the pipeline.

    Monday, April 30, 2007 11:19 PM
  • No mistake on the transcription, the UNC is as quoted (minus the sanitization).

    You are quite right. Been reading the specification it this violates the specificatio. Been checking all the messages that have flowed the production (the system R2 is going to replace) and all messages of this type are like these. Very strane, will have to check with my client. This system is in production for quite a few years.

    I guess this leads me with the next (related) question. How can i generate the return message with the error?

    Should i subscribe for suspended messages on the receiving pipeline? or is there a better way to acommodate this?

    Thanks for your help
    Tuesday, May 1, 2007 2:30 AM
  • Slight correction. UNB8 (processing priority) is of type alpha and should be a single character that is allowed by the encoding type in UNB1.1

    Tuesday, May 1, 2007 8:29 PM
  • What do you mean by the return message? Are you talking about the Technical and/or Functional Ack?

     

    If so, you can set this option at both party and global level. To do so, go to "EDIFACT/Party as Interchange Sender/ACK Generation and Validation" and check the "Generate Technical ACK" or "Generate Functional ACK".

     

    Once you have done so, you can subscribe to the ACK by using the filter BTS.MessageType == http://schemas.microsoft.com/Edi/Edifact#Efact_Contrl_Root and EDI.UNB2.1 to be equal to the payload's value.

     

    Hope this helps

     

    Mohsin Kalam

    Tuesday, May 1, 2007 8:39 PM
  • Thanks for the tip.

    I'm not sure if this is want, but it probably is :-)

    But i'm going to study your tip, to see if it fits my needs.

    If i understand correctly, if i set the mentioned options and an invalid message is received, BTS will automatically generante an edifact Control Message. I can subscribe it, and do whatever i want. Is this correct?

    Thanks.
    Tuesday, May 1, 2007 8:57 PM
  • Yes that is correct. The Control Message will contain detailed information on the error down to the field element level. That can be used to diagnose the reasons why the message failed. Another way would be to subscribe to the EDI error generated by the EDI Receive Pipeline.

     

    Tuesday, May 1, 2007 9:41 PM