Reading Value of a field from one scenario to another

[Former Member]

Hi,

I have two scenarios in place. The first one is IDoc to SOAP. The IDoc no. is of course generated while this scenario is executed. In the other scenario, however I have SOAP to file, which gets triggered when the first scenario runs. My only requirement is that the IDoc No. which was sent in first scenario, should be written to a field in file in the second scenario. Thus, if I trigger the IDoc to SOAP scenario with IDoc no. as 223344, then when the second scenario runs from SOAP to file, I should get 223344 in the field of file structure. I dont want to have a ccBPM nor will that webservice return me the IDoc No. Please advise if this could be done.

Regards,

Singh.

[Former Member]

Hi,

Unfortunately it will not be possible for me to do this with any ABAP tables. Is there any other way for this. Can having a global variable in function library be of any help? Does a global variable work outside one mapping? Is it possible to manipulate dynamic configuration to achieve this scenario.

[ambrish_mishra]

HI,

Global variables do not work outside the mapping. Dynamic configuration also won't help. these are 2 different scenarios. Unless you are going to store the IDoc number somewhere, you can't retrieve it. Another storage option would be a file if not a table but not sure what would be a good solution.

Ambrish

[manigram]

Hi,

Get the Idoc no from 1st scenarion and save it in to PI ABAB table. So now u have the idoc number in PI server. In  the 2nd scenario create RFC look up and pick the idoc number from ABAP table, send it to target system. Make sure the 2nd scenario should execute after 1st scenario get executing.

[MichalKrawczyk]

Hi,

a) in pleace where IDOC is generated add a field to the IDOC (OLD_IDOC) and populate the number there so it will be visible in IDOC - SOAP scenario

b) you can make a lookup in mapping and get the old IDOC number from there (from links like document number, etc.)

there's no need for ccBPM at all in this scenario,

Regards,

Michal Krawczyk

[Former Member]

Hi

Could you please elaborate more on the above solutions. Please note that the webservice cannot return me the IDoc No. sent to it. It is such that one scenario gets executed with some IDoc No. & then the second scenario executes with the IDoc No. populated in target side.

[baskar_gopalakrishnan2]

In the first scenario update that field information in a table or some file in mapping. While doing second scenario do lookup example(jdbc) and retrieve that value and send it to target file structure.

You might want to see jdbc lookup or file lookup links in SCN.  refer this link for file lookup

http://wiki.sdn.sap.com/wiki/display/XI/File+Lookup+in+UDF

You dont need to use ccbpm for this.

[ambrish_mishra]

Hi,

the solution will depend upon the frequency of the interface both outbound and inbound. If it is periodic, you can simply update a Z table in PI ABAP stack (not recommended in PI) on the outbound interface run, with the IDoc number and read the same on the interface inbound which creates file. It can be done through an RFC look up of the table which writes the IDoc number and reads the IDoc number on the return leg and marks it as read.

But some things to consider here... what if the outbound interface runs and the inbound interface does not run for whatever reasons and the outbound interface again runs and update the table with another IDoc number... the inbound interface which runs now should know to pick the old record and mark it as read.

So its better that along with the IDoc number, you store a key field in the Z table which identifies the record and the inbound interface which should create a file should validate the record with the key field before it picks the IDoc number to write in file and mark it as read.

next time, the RFC should only read records which are not marked read and with the key field returned from SOAP.

Hope it helps!

Ambrish

PS: The frequency of the interface will be critical here since table locking issues may arise if it is too frequent.