1:N multimapping with wait without ccBPM

[Former Member]

in my pi7.0 system , I rcv a message , which has to be split into two... and at rcvr side.. the second msg should post 5 mins after first message..

I can do this in ccBPM.. but is there a way without it?

say sleep in map step? possible?

[markangelo_dihiansan · Accepted solution]

Hi Lalrem,

Sleep in the mapping is possible. This is done via UDF by adding thread.sleep(300000); 300000 is 5 minutes in milliseconds. However, it might harm your system in the long run. The thread containing the second message will only get released after 5 minutes.

How many times are you executing this message/day?

Regards,

Mark

[Former Member · Accepted solution]

Hello Mark... This is a multi message.. 1:n mapping.. hence if i use sleep method.. the entire mappign goes to sleep...

i want the first target message to be executed and then the second target msg to wait

[former_member190293 · Accepted solution]

Hi Lalrem!

At first, I would try to clarify the requirement. For example, do I need 5 minutes delay or start of processing the second message only after the first message has been successfully processed.

If you need delay, I would try with custom adapter module at receiver adapter, which takes some indicator (or even delay interval) from payload or DC (to avoid additional parsing of message), for example, and if it exists - to use thread.sleep() in your adapter module code.

Regards, Evgeniy.

[anupam_ghosh2]

Hi Lalrem,

                 What kind of adapters you are using in sender and receiver side?

Regards

Anupam

[Former Member]

File to idoc1 and idoc 2

[former_member194786]

Hi Larlem,

If you route the second message on PI server using a SOAP call and then introduce a wait step in the second iteration, you will be able to achieve this. Flow would be like:

1) Sender 1 --> SAP PI --> Receiver 1

                                   --> SAP PI

2) SAP PI --> SAP PI --> Receiver 2

But, as Mark has mentioned above, be careful when introducing these kind of delays in mapping. If your interface executes limited number of times in a day, it may be ok to block a thread, Else if it is a high volume scenario, it may not be best idea to keep blocking threads in your system.

Regards,

Sanjeev

[former_member186851]

Hello Lalrem,

Mark is correct.

Check the below link