HTTP --> RFC

[Former Member]

Hi,

I have HTTP --> RFC synchronous scenario.

I need to call 2 RFcs.

First the RFC1 is called synchronously and then evaluating the result RFC2 will be called.

The response of RFC1 or RFC2 should be returned as HTTP Response.

I could realize this using sync-async bridge of BPM.

But Is this posssible without using BPM?

I tried RFC Lookup for first RFC but dont know how to check condition based on Response of RFC1 (whether RFC2 should be called).

Thanks,

Beena

[prateek]

<i>The response of RFC1 or RFC2 should be returned as HTTP Response.</i>

If this is the case, wherein response of both the RFCs could go to the HTTP, then u cannot avoid BPM. Bcoz a sync scenario without BPM could get a response from only one receiver (only 1 RFC in ur case).

Regards,

Prateek

[Former Member]

Hi,

Thanks.

I think I will have to use BPM.

But I can have sync-async bridge with receive-open S/A bridge and in mapping I can use RFC lookup to call 2 RFCs and the result message of mapping can be sent using send step - close S/A bridge.

i.e. I will have BPM as receiver for my scenario.

I think I can avoid multiple receive and send steps and also transformation step for n:1 mapping (to map input from HTTP Request and Response of first RFC to Request of second RFC) by using RFC lookup.

Thanks,

Beena.

[henrique_pinto]

Beena,

probably you are right regarding performance only.

But in therms of monitoring, lookups may become a real pain in the @$$, even more if you have 2 lookups in the same mapping.

And in order to avoid to 2:1 mapping, couldn't you evaluate simple condition on RFC1 response using switch step? Or you do need RFC1 response message to create RFC2 request?

Regards,

Henrique.

[Former Member]

Hi Henrique,

I do need RFC1 Response to build RFC2 Request so I can not avoid 2:1 mapping.

Yes, you are right that monitoring will be difficult but I will require 1 receive , 3 send and 1 transformation step in BPM which will have impact on performance.

How useful will it be if I use AbstractTrace object in mapping to add trace info for monitoring?

Thanks,

Beena.

[henrique_pinto]

Using AbstractTrace in mapping, you'll have more ways for debugging your interface, but again, it will not be the best tool for monitoring.

However, I'd do some benchmark tests to check what will be the impact of having both scenarios (full BPM and lookup) in your interface. From PI 7.0 SP10, transaction handling has improved BPM performance.

Regards,

Henrique.

[Former Member]

Hi,

IMHO, a wrapper RFC which exectues RFC1, evaluates the result(export values) and if required execte RFC2 and return the result(result of RFC1 and/or RFC2) is better. BPM is an over kill if you are allowed to put the wrapper RFC.

cheeers

danus

[Former Member]

Hi Chidambaram,

Thanks for reply

but It is not possible to put wrapper RFC.

Thanks,

Beena.

[prateek]

Hi Beena,

1 more point abt the performance issue.

While designing ur scenario, if ur sender data frequency is very high or the payload is very large with multiple occurrences of same element, then RFC lookup again n again will hamper the performance.

Make sure that suppose there r 100 line items then RFC lookup is not done 100 times otherwise it will drastically degrade tge performance

Regards,

Prateek

[henrique_pinto]

Either you use BPM or Wrapper RFC to emulate the logic.

I dont see how lookup would work in this case, because suppose you have Sender -> RFC2 integration and in mapping you have lookup for RFC1. You cant say "dont trigger RFC2 anymore, send this output directly to the sender".

Regards,

Henrique.