Skip to Content

JMS to IDoc - Sequence / Numbering

Dear all,

I'm a little confused about this behavior, maybe you could give me some ideas on why this is happening.

I have a JMS (MQ) --> PI --> ERP scenario where the messages on MQ are of course in sequence.

I configured my JMS sender adapter with QoS EOIO and gave some arbitrary Queue ID (Z_GAL1) and the Cluster ID (Its not actually a cluster, but only one server node)

I also configured the interface determination to use EOIO

I intentionally didn't activate the IDoc receivers "use queue processing" because we have multiple IDocs that need to be processed in sequence but only if they share the same order number which is in the payload of the IDoc. Having fully queued proccessing would mean that any error in a previos IDoc would lead to a stop of the queue even if IDocs with other order number could be processed successfully.

So the strange thing is this: MQ provides the messages in strict FIFO sequence. PI receives those messages in the correct order. This is visible in communication channel monitoring. However, the generated IDoc Numbers are not in sequence.

  1. Is this a normal behavior of the IDoc adapter on PI (7.0 Dual Stack)
  2. I know about IDoc / ALE serialization. I could fill in SERIAL field. However, since we have another legacy system that posts those IDocs to ERP which in fact creates IDocs in strict FIFO sequence and inbound processing for those is already working and tested I would like to have PI behave the same way as much as possible as the legacy system. Is there a way to accomplish this?

Many thanks.

Kind regards

Jens

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

4 Answers

  • Best Answer
    Jun 20, 2014 at 11:41 AM

    Dear all,

    after some testings on new SAP PI 7.4 AEX (original tests carried out on SAP PI 7.0 Dual Stack) it seems that by specifying the following parameters in the sender JMS adapter does the trick

    QoS = EOIO

    Queue ID = Some arbitrary name like "MyIdoc"

    Processing J2EE Cluster Server = Your Cluster ID. Probably also would work if left blank

    So as of now I'm not quite sure if I didn't carry out all the steps on PI 7.0 correctly or if this behavior was changed in PI 7.4. Anyway, the Messages get picked up from JMS Queue in the correct order an IDoc numbers are getting created in a sequential way.

    I then filled in the SERIAL field with a built in function "currentDate" / Target Date Format = "yyyyMMddHHmmssSSS" in normal graphical message mapping.

    I did not activate Queue Processing on the receiver IDoc adapter nor the assosiated port (WE21) in corresponding ERP system.

    I configured the partner profile in ERP for background processing so the IDocs get collected in ERP and then processed periodically with a job that puts the IDocs in the correct order according to the SERIAL field.

    Hope this helps someone out there

    Cheers

    Jens

    Add comment
    10|10000 characters needed characters exceeded

  • Apr 17, 2014 at 06:34 AM

    Hi Jens

    EOIO is available for the IDoc adapter - refer to the screenshot below from the following link:-

    Adapters - Integration Directory - SAP Library

    If you check the details of the IDoc adapter, there is a section regarding serialization setup (check link below)

    Serializing IDocs - Configuring the IDoc Adapter - SAP Library

    This would require the "Queue processing" option on the IDoc receiver channel.

    I understand that you do not want all the IDocs in the payload to be serialized, only those with the same order number. Here are my two cents on a possible approach:

    You can split the original payload from JMS into two interfaces - 1 to the IDoc for non-serialized orders, another 1 to a "intermediate" interface for the serialized orders. Then have a second scenario to process the serialized orders in EOIO and send it to a different IDoc receiver channel with "queue processing" checked.

    The two scenarios would look like this:-

    For the "intermediate" interface, you can channel it to a temporary File/FTP location, or you can use the SOAP adapter and do a loopback from the SOAP receiver of the first scenario to the SOAP sender of the second scenario.

    Rgds

    Eng Swee


    eoio.png (15.3 kB)
    scenario.png (6.9 kB)
    Add comment
    10|10000 characters needed characters exceeded

    • Hi Jens

      I think I misunderstood the requirement 😕 I thought there were a few orders within the same payload from JMS, so that's why I suggested the multi-mapping for the first step.

      If the messages from JMS are already coming in the right sequence, and there is a Serialization field in the payload, then you can use the "intermediate" approach and write to a temporary location with that field in the filename (using variable substitution.) For the second step, you can set Processing Sequence of the File sender channel to "By Name". Do note that this is only available for the NFS protocol.

      Having fully queued proccessing would mean that any error in a previos IDoc would lead to a stop of the queue even if IDocs with other order number could be processed successfully.

      Before you go for that solution, I'm still a bit curious what are your concerns above about having "queue processing" in the IDoc receiver channel. What type of errors are you worried about? What is your setting in the partner profile in ERP - trigger immediately or background? It should be quite safe if you are using background - because the application processing will be by a different job and therefore might not block the IDoc adapter.

      Also, I think this serializing via Queue Processing in the IDoc adapter only involves delivering the IDoc to the ERP system and is not the same as the ALE/IDoc serialization on the backend (I need to check on this to verify my assumption.) This would then be exactly what you want.

      Rgds

      Eng Swee

  • Apr 17, 2014 at 08:41 AM

    Hi all,


    thanks for your your participation so far. Funnily enough in PI IDX5 I see that the IDocs get created (creation date / time within PI) in wrong sequence but the IDoc number within PI seems to be in sequence with the creation time from the sender system:

    Creation Time within PIIDoc Number within PICreation Time from sender system15:31:4234902915:31:3915:31:4434903215:31:4115:31:4434903315:31:4215:31:4434903115:31:4015:31:4434903015:31:40


    Is there any way to force PI to send IDocs in sequence of the PI IDoc number rather than (so it seems) FIFO regarding creation time within PI? I know, there's queued processing for this but queues would probably not be feasible due to unwanted blockings of a whole queue even if different order numbers are affected.

    Thanks and kind regards

    Jens

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Apr 17, 2014 at 05:57 AM

    Hi Jens

    If you were using Proxy in ECC side, then the EOIO option would have worked perfectly and

    all the messages could have processed sequentially.

    But as it is Idoc, I don't think it will be able to generate the idoc sequentially.Once the messages are

    processed in PI, they will go in SM58 for tRFC processing.

    And in case of tRFC the EOIO concept will not work.

    You need to use serialization if you want to maintain the sequence.

    Add comment
    10|10000 characters needed characters exceeded