Determine receiver depending on ABAP function module return value

[Former Member]

Hi all,

I have a File-to-File scenario in XI. When the Input file comes in, I have to parse it and insert values of fields to a z-table. I'm able to do this on the mapping.

One field in the input xml, say ID, is a primary key in my z-table. When the input file has an ID that already exists in the z-table, I have to drop the file to a different folder, otherwise just map it and drop it to a different folder.

I have a ABAP Function Module which takes in parameters and inserts values in the z-table. On the mapping I have a user defined function, that calls the ABAP FM with parameters. The FM returns true or false depending on whether the insert was successful. I'm able to do this.

The problem is, when the insert fails and I have a return value = false, how do I drop the file into a different folder. How do I use conditional receivers for this (one receiver for successful insert, another for failed insert). I do not want to modify the source message.

Please help.

Thanks

Karthik

[moorthy · Accepted solution]

Hi Karthik,

As you are inserting the table thru mapping, if you want to achieve these conditional Receivers, it is better to introduce BPM here,

So in the BPM, you are going to execute the Mapping. And after output, with Switch statement, based on true/false, you are going to send the file into 2 diffrent folders.

Hope this helps,

Regards,

Moorthy

[henrique_pinto · Accepted solution]

Moorthy,

even with BPM, what could he do here?

He has message A, which he must send to system BS1 or BS2 according to message B. If he makes a switch on message B, what would be the two branches? Wouldn't it be send steps, sending message A, exactly equal? He couldn't make a conditional receiver determination either (because the content of message A is the same).

I've had this same doubt before.

Regards,

Henrique.

[bhavesh_kantilal · Accepted solution]

Henrique,

<i>when the insert fails and I have a return value = false, how do I drop the file into a different folder.</i>

This response will be available in a conatiner element in the BPM. You can use Switch step in the BPM to stich over the value of this element and then have the corresponding Send Steps in each of the branches of the Switch Step.

Each Send Step wil have a separate Message Interface accosiated with it, and thereby separate Reciever determination and so on.

Regards,

Bhavesh

[henrique_pinto · Accepted solution]

Bhavesh,

as I've understood from the request, the message interface was the same.

So, as I had expected, the only way of doing this is using different message interfaces, right? Even though the message type is the same, you must create different interfaces in order to send it to different receivers, through BPM.

Other than this, I can't see a way of making this work (even using enhanced receiver determination).

Regards,

Henrique.

[bhavesh_kantilal · Accepted solution]

Henrique,

<i>So, as I had expected, the only way of doing this is using different message interfaces, right? Even though the message type is the same, you must create different interfaces in order to send it to different receivers, through BPM.</i>

yes, you do need different Message Interfaces to send to different receivers and that is what I think moorthy too implied in his answer to this thread.

Regards,

Bhavesh

[bhavesh_kantilal · Accepted solution]

Henrique,

If he uses Extended Reciever Determination which is available from SP 16 onwards, he will have a mapping between the Source and the Receivers Message Type. Do the logic ( by making the RFC call etc to the target ) in the mapping to determine the reciver and then call then assign the receiver to the target.

Extended Receiver Determination allows you to choose receivers using a mapping step unlike the earlier Dynamic Receiver Determination which was based only on the source message.

Hope this clears,

Regards,

Bhavesh

[henrique_pinto · Accepted solution]

Bhavesh,

You're right, I hadn't thought of the possibility of making the rfc lookup on the receiver determination mapping, but on the BPM.

Your way should be better.

Regards,

Henrique.

[bhavesh_kantilal · Accepted solution]

Henrique,

It was a pleasure. Wish there were more such threads on the forums where design approaches are discussed threadbare.

Regards,

Bhavesh

[Former Member · Accepted solution]

Hello All,

I thank you all for your inputs. I haven't had time to go over in detail. Will work on it and respond.

FYI, I'm on SP16.

Thanks

Karthik

[Former Member · Accepted solution]

Hello All,

I thank you all for your inputs. I haven't had time to go over in detail. Will work on it and respond.

FYI, I'm on SP16.

Thanks

Karthik

[Former Member · Accepted solution]

Moorthy,Bhavesh,Henrique

The question I have here is, where to I store the return value of the RFC call. I do not want to manipulate the source message (like storing the value in a field, and on the BPM checking for this field if its true or false). How can I check for the condition in a switch statement in the BPM without the return value not being stored in any field of the source message?

Am I missing something here? If possible could you give a detailed description of what should be done once I have the return value from the RFC call.

Thanks

Karthik

[Former Member · Accepted solution]

Hi,

I resolved this problem as follows.

I raised an exception on my Function Module when the primary key is violated. This would cause the mapping to fail. I created a BPM having an exception branch for a transformation. When the mapping fails, on the exception branch I send the message to a different Business system (or drop it to a different folder). This seems to work.

If you've got any better ideas, please post them.

Thanks a lot for your replies.

Karthik

[henrique_pinto · Accepted solution]

I guess the no-BPM-with-RFC-Lookup-on-the-enhanced-Receiver-determination-mapping approach would be more performatic, though the exception approach seems to be conceptually more correct.

Regards,

Henrique.

[Former Member · Accepted solution]

Henrique,

I agree. With the exception approach, I can also filter out messages that fail the mapping due to erronous input data. Serves dual purpose.

Thanks

Karthik

[Former Member · Accepted solution]

Hi,

I'm stuck at another issue now. How do I differentiate the exeptions caused by mapping error in the BPM?

The transformation would fail when the primary key is violated in the z-table or when the structure of the input message is wrong.

How do I handle these two cases differently?

Please reply.

Thanks

Karthik

[agasthuri_doss · Accepted solution]

Dear Karthik,

Thru CCBPM you can handle it.

Kindly let me know any clarifications.

Regards

Agasthuri Doss

[bhavesh_kantilal]

Kartik,

Which SP are you on? If Sp16 and above you can do enahanced receiver determination. Take a look at this blog,

/people/venkataramanan.parameswaran/blog/2006/03/17/illustration-of-enhanced-receiver-determination--sp16

Else, you need to go for a BPM as explained by Moorthy.

Regards,

Bhavesh

[henrique_pinto]

Bhavesh,

that wouldn't help either because enhanced receiver determination will use message A as input (and so, the receiver determination mapping will be over this message), but in this case the receiver need to be decided over message B.

Regards,

Henrique.