cancel
Showing results for 
Search instead for 
Did you mean: 

B1i 2.0 losing information

MHollender
Explorer
0 Kudos
245

Take a scenario like this. Read a file that contains a new customer data for Business Partners, run an SQL call to see if the customer already exists, and if not then insert.

CRON -> FILP -> XSLT -> JDBC -> XSLT -> BRANCH -> XSLT -> CALL Service Layer.

Problem: even when using Adjust To Smart Messages (and enabling them in the package) and Keep Inbound Payload Everywhere, after the JDBC call the data you originally imported from the file is not in the message flow anymore, it is lost, all you have is the result of the SQL call. But you need that data obviously in order to insert the customer. Same thing with SL or DI calls.

In V1 you could refer to all previous atoms, but in V2 no matter what you do the earlier atoms are just not kept in the flow.

Use memvars? Cannot store a customer with 100 addresses in them.

Use persistency to BizStore? IMHO overkill. And how can you delete it after your are done?

How is everybody doing it? How do people implement the pattern of

import file -> check stuff -> insert data -> insert into a log table -> etc.

in V2 when you cannot at the later steps refer to the earlier steps and their data because calling JDB erases the data from the flow?

View Entire Topic
MHollender
Explorer
0 Kudos

Answer: does work in Deployment, just not in Test Environment. The Test Environment is buggy and the SAP developers always use Deployment.

MHollender
Explorer
0 Kudos

Hi! joao.ferreira10

That was not the issue. The issue is Branch, unlike the IF statement in a normal programming language, only provides to the next step what you are branching on.

A very typical approach is: Split-Join, like, a FOREACH statement on making DI Calls. It requires a Branch, because if there are no nodes, it error messages.

So the logical thing is that your Branch condition is //Envelope2 but in that case you get only that in the DI Call and thus cannot for example write a log of what input data you were processing.

So the branching has to be done the super not intuitive way. Copying your code from b1if to Altova XMLSype, right click on Envelope2 to get the whole XPath (usually I just //everything), modify it around and have stuff like /vpf:Msg[count(vpf:Body/vpf:Payload/Msg/ToDI/Envelope2)>0]

I tried it simpler, like

/*[count(./Envelope2)>0]

So that I would not need to care about always finding the whole path, but it did not work.

And there is no documentation on how you should do branching, so I just spotted it in a video of Krisztian Papai which was about something else.

So this was super hard.

Of course I might just not iterate over it at all, but rather just make one big batch of DI call in one simple atom, but when I try that, it sometimes crashes running out of memory when processing a DI Call with 10000 calls. So each DI call bein one record is safer...

Seriously b1if is super not intuitive, and one could do the work of importing an XML file to the Service Layer with five lines of powershell much faster than how branch and split works. You cannot even change the value of a variable in XSLT... super hard to use programming language.