cancel
Showing results for 
Search instead for 
Did you mean: 

About the quality of service "Best Effort"

Former Member
0 Kudos

This is my scenario:

File -> XI -> SAP

The scenario is fine, and I want to try the "Best Effort" quality of service.

First, I change the username of SAP communication to a invalid username.

Second, I change the process mode to "Delete"

Case 1:

QoS is "Exactly Once": although XI cannot call SAP RFC, but the file is still deleted.

Case 2:

QoS is "Best Effort": the same as case 1, XI cannot call SAP RFC, but the file is NOT deleted.

So, should I use "Best Effort" for these kind of scenarios? I think it's good, because when SAP is not available, we don't need to resend files. But if there any impact ?

Actually, I still have other scenarios like MQ -> XI -> SAP, JDBC -> XI -> SAP, and should I use "Best Effort" for them ?

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

>>>I think it's good, because when SAP is not available, we don't need to resend files. But if there any impact ?

I dint get this point. What do you need to do if the receiver(SAP) is down?

If the receiver is down, it will result in an error in SXMB_MONI. It is possible to reprocess the failed msg. You can resend them to R/3 when it is up again...

Regards,

Jai Shankar.

Former Member
0 Kudos

> I dint get this point. What do you need to do if the

> receiver(SAP) is down?

This scenario is very simple, XI loads data from a file and input a table through a RFC. (Acknowledge is not necessary.)

My point is, I know I can restart a message sometimes. But think about it, if I have 500 files? (Maybe files is not a good sample, think about database or JMS), I need to restart many messages. And if XI doesn't delete the files when SAP is not available, then when SAP is back, we don't need to do anything ?

My wish is, when some external resources (i.e. SAP, MQ, database, ...) are not available, we don't need to do anything in XI (i.e. restart message) when these resources are come back.

btw, for case 1, I cannot restart it in SXMB_MONI, is there any suggestion to check it ? When I can restart and when I cannot restart a message ?

Former Member
0 Kudos

>>This scenario is very simple, XI loads data from a file and input a table through a RFC

Your current configuration should suffice this requirement..

>>I cannot restart it in SXMB_MONI, is there any suggestion to check it ? When I can restart and when I cannot restart a message ?

You can restart all message with error status in SXMB_MONI. You cant restart a msg with status"processed or scheduled".

>>My wish is, when some external resources (i.e. SAP, MQ, database, ...) are not available, we don't need to do anything in XI (i.e. restart message) when these resources are come back.

I fear this is not possible.. Reason.

File adapter is going to poll for files based on the polling interval. It has no way knowing the receiver status...

Regards,

Jai Shankar.

Former Member
0 Kudos

Thanks for your reply, but I still have two questions

1. Although file adapter doesn't have sync mode, what's the difference between "Best Effort" and "Exactly Once" of file adapter ? (In my test, their behavior are different.)

2. We has several hundred interfaces between SAP and other systems, we just migrate a little to XI now. Last week, our SAP is not available for a while, before SAP is available, our solution is to stop the communication channel of all senders. (about 7-8 senders). The scenario is JDBC -> XI -> SAP and MQ -> XI -> SAP. The messages cannot restart (we use SXMB_MONI and it shows "restart is not possible"). If we migrate all interfaces to Xi someday and SAP is not available and message cannot restart, is there any suggestion for it ?

Why I ask this question, because if I don't use XI and write a adapter myself. This will be my algorithm:

1. Get files (or get message or query database)

2. Call SAP RFC

3. If the RFC result is successful, then the file will archive/delete the file (or commit the message or update the datebase)

4. If the RFC is fail or SAP is not available, the the program will do exception handling (i.e. if SAP is not available, the program will wait 10 minutes and try again. if the source data format is not correct, then this program will send mails to system owner.)

I think the algorithm is reasonable, am I right ? I still think system owner need to manual restart messages is strange, system should do this job itself.

Former Member
0 Kudos

>>1. Get files (or get message or query database)

2. Call SAP RFC

3. If the RFC result is successful, then the file will archive/delete the file (or commit the message or update the datebase)

4. If the RFC is fail or SAP is not available, the the program will do exception handling (i.e. if SAP is not available, the program will wait 10 minutes and try again. if the source data format is not correct, then this program will send mails to system owner.)

Just a beautiful algorithm infact. But if you need to put this algm into a program that can do the work for you, belive me it is not going to be avery easy job.....

My suggestion is go for XI which provides all the services you specified in your algm...

To simulate your algm using XI, you need a BPM...

I am not sure, why you can't restart your msg in SXMB_MONI. If you are using async interface and the msg status is "error", you will defeenitely be able to restart it in SXMB_MONI..

Regards,

Jai Shankar.

bhavesh_kantilal
Active Contributor
0 Kudos

Hi,

QOS Best Effot is used for Synchronous Processing. You file adapter does not support a Synchronous Processing and so as you are calling an RFC and need to push the response back to the File, you would need a BPM, FILE --> RFC --> File.

make the QOS of file as EO or EOIO and then use this blog,

/people/arpit.seth/blog/2005/06/27/rfc-scenario-using-bpm--starter-kit

Regards,

Bhavesh

Former Member
0 Kudos

Hi Dennys,

File adapter does not supprt acknowledgements. So you need to go only with "EO". If you need error handling in your scenario, try configuring alerts with CCMS or if performance is not a bottle neck, go for a BPM with Exception handling...

P.S: JDBC sender adapter also does not support acknowledgements..

Regards,

Jai Shankar.