Proxy to JMS Scenario: switch from sync to async proxy,does it makes sense?

[Former Member]

Hi @all,

i've implemented a sync proxy to JMS scenario that works well. Backend is ECC 6.0 and Middleware is PI 7.1.

Business Case: Run a request with a number and get a response back with a corresponding entry for the number. That means, there is always a response expected.

Now the following thing appears: the receiver system could not handle many calls at one time (200 calls are planned at each run), the calls reduces the performance. Now gys at receiver system likes to develope a buffer of 10 seconds between the requests to handle some kind of load balancing with that. That means for the request that it the response takes +10 seconds back to backend. It is also possible to handle that in SAP backend with a waiting-statement in coding, so there is no need to go from sync to async - but the customer requested us to implement this scenario in async.

JMS is always async, I know. But the Service Interfaces for Inbound and Outbound are of mode sync - so I can call my outbound Interface class in backend with Importing Output and Exporting Input.

My question is: makes it sense to go from sync to an async scenario?

And how looks the coding in backend for the response? I guess that it only makes sense to switch to async when no response entry is needed (example: for write operations).

Thanks in Advance,

Stefan

[rajasekhar_reddy14]

Hi,

RequestOneWayBean,Wait response bean in JMS side,it avoidn BPM.

if you want to add some time delay then write simple UDF and add wait method may be 10 sec like that and try in sync mode only.

Regards,

Raj

[Former Member]

Hi Raj,

thanks for your resonse.

The thing is, that the customer would implement the "10-sec-wait" at the provider-side, so there is no need to implement this in PI (I also thought about UDF in case of PI-development).

But do I need to switch from sync to async?

Thanks,

Stefan

[Former Member]

Hi,

here is an addition:

the backend calls are automated running via job.

Regards,

Stefan

[Former Member]

Adding 10sec wait at source side is just perfect solution since it is a synchronous scenario.

No need to switch.

[Former Member]

Hi,

thank you for your answer - I think that is the best solution and I'm going to advice the customer for that.

But in case of switching, what is the best way?

Should I implement 2 senarios? Or is it ok to switch the Inbound and Outbound Service Interface from sync to async?

Thanks,

Stefan

Edited by: Stefan Burghardt on Jul 4, 2011 12:20 PM

[Former Member]

> the backend calls are automated running via job.

Just to clarify, you mean the background job runs the program and triggers the sync outbound proxy to send the question and then JMS will send back the response with 10 sec delay to R3? If yes then it should not be an issue.

[Former Member]

> But in case of switching, what is the best way?

> Should I implement 2 senarios? Or is it ok to switch the Inbound and Outbound Service Interface from sync to async?

I don't think you need 2 scenarios for this. Just one is enough with different RDs.

Over all in this case you have to re-create/modify the service interfaces and also you have to create 2 interface mappings. You have to also create the new inbound and outbound proxies since service interface mode will be changed. For outbound proxy the code can be reused and for inbound proxy also logic and code can be taken from your old code.

[Former Member]

Hi,

"Just to clarify, you mean the background job runs the program and triggers the sync outbound proxy to send the question and then JMS will send back the response with 10 sec delay to R3? If yes then it should not be an issue."

-> Yes, this is what I tried to explain, sorry for any misleading.

The background job runs the program, the program triggers the sync outbound proxy with the request and the JMS sends answer with a 10 sec delay back to R3.

Regards,

Stefan

[rajasekhar_reddy14]

If you are going to maintain time delay in R/3 program, then JMS side no need to add time delay.

your design looks correct...go with that

[Former Member]

Hi @all,

here is the solution: the provider configures their server parameter so it is no longer a problem of receivig mass data - the delay in backend is obsolete and I can let the scenario be sync.

Cheers,

Stefan