MessageSplit with XSLT and without BPM

[Former Member]

Dear all,

I'm on PI 7.0 SP 16 and I've the following scenario:

JDBC-Sender-Adapter delivers a resultset of multiple rows, for example

<?xml version="1.0" encoding="utf-8"?>

<resultset>

<row>

<PIDENT>T400000TEST6A1MA</PIDENT>

<ARC_DAT>19970804093738</ARC_DAT>

</row>

<row>

<PIDENT>T400000TEST6A1MI</PIDENT>

<ARC_DAT>19970804093738</ARC_DAT>

</row>

<row>

.

.

.

</resultset>

For each row in my resultset I would like to process one message to the same inbound interface, so runtime should be faster than querying row by row.

How can I achieve this by a multi-mapping? Do I have to provide the Messages/MessageN tags in my xslt-mapping-output?

Kind regards

[Former Member · Accepted solution]

>? Do I have to provide the Messages/MessageN tags in my xslt-mapping-output?

>

Yes, if you are going with the option of mapping based message split with you XSLT mapping , you need to include Message and MessageN tags as the top nodes in your target msgs.

Pooja

[Former Member]

Hi,

I can't see your logic of speeding things up by splitting the file. What you should remember is, the file gets split in the message mapping pipe line step, if you use multi map.

Now all you are doing is ,adding overhead to the runtime to perform so many more calls(multiple call to all the steps to the pipe line and adapter steps after message mapping instead of justone call). There is a performance graph available to look at in sdn, I think its in one of the how to guides on performance. It clearly shows the optimum performance is not given by too small or too large files. So even if you get a level of parallel processing by splitting the message, you might well be offsetting it by the overhead .

cheers

dan

[Former Member]

Hi,

thanks for your reply. What do you think about processing the resultset (or chunks of it) as one message and to split it up at the receiver system?

Kind regards

[Former Member]

I would treat it as one message and do the mapping and send it to the receiving end. But you need to look at the capabilities of the system that receives the file to make that final design call.

>

> Hi, 
> 
> thanks for your reply.  What do you think about processing the resultset (or chunks of it) as one message and to split it up at the receiver system? 
> 
> Kind regards