​Replacing Split with queues in b1if?

[MHollender]

I do a lot of b1if scenarios where I write business logic in a HANA SQL Stored Procedure for example generate invoices, then I send them to the DI via b1if. I could get 10000 lines in SQL or 0 lines.

So it is like Call SQL -> Branch IF there are any jdbc:Row -> SPLIT and process each row -> transform -> call DI - join - write log.

I would like to simplify it. Very error prone and hard to debug.

But if I do not Split just make one huge DI transactions with 10000 Envelope 2 it takes forever to process and may crash, run out of memory.

nidhisingh14 recommended using queues, but I still need to Branch - Split and send each to the queue separately? Or is there a clever way to avoid that?

(BTW I invented a cool way how to generate Documents from HANA SQL Stored Procedures via b1if. The crucial thing is that my SQL uses column names the same as DI field names. So my xslt loops over all columns and automatically maps them. Except columns that start with XX_, usually XX_DocEntry, linking header and line. So if I need to add a new field, I only extend the SQL and do not have to deal with this difficult xslt. I just wanted to share this.

Right now experimenting with doing the same for importing XML files. Send them to a stored procedure as a table, run business logic there, and get them back as DI compatible SQL results. xslt is terrible for a lot of business logic, Hana SqlScript is much better and it has access to reading all data for checking, validating results)

[PierreBrothier]

Hi Miklós,

we have faced the same problem.

Even if you try to use queue, you'll have an incoming payload too big, which leads to freeze or crash.

Starting with an SQL Call, we have choose to limit the number of row returned by the query, then put each row in a queue.

Smaller payload = faster scenarios.

I would also use Service Layer instead of DI API, as it is really faster.