How to use a global variable value into different executions of same ccBPM

[Former Member]

Hi all,

I want to share with you a problem that I have in order to discuss the better approach to use.

Requirement:

On a ccBPM using SAP PI 7.1 EHP1 we need to deliver via JDBC adapter some information to a database A on server X, if at some point there is an error (of any type), we need to deliver this information to database B on server Y, and continue with the ccBPM remain steps.

Problem:

After the first delivery of the information to database B on server Y, all the subsequent executions of this interface must deliver the information only to database B on server Y, discarding any intent of delivering the information to database A on server X.

With that in mind we have the following question:

How to use a global variable value into different executions of the same ccBPM?.

Possible Solutions that we are evaluating so far:

a) Controlling the status of the communication channel

b) Modifying at execution time a value mappings current value

c) Using a Z table in the ABAP Stack of PI via RFC

d) Still looking

Any suggestions?.

Best regards

Edited by: Eric Hernandez Pardo on Sep 15, 2011 2:58 PM

[henrique_pinto]

You mean the next bpm instances should completely ignore server X forever??

What would be the criteria for the system to send data to server X again?

BR,

Henrique.

[Former Member]

Hi Henrique,

That's the idea. All the following BPM instaces should ignore Server X.

The criteria to restore the data delivery to Server X could be in the following cases:

- 12 hours later of the appearance of the problem and/or

- Update somewhere the value manually and/or

- Another interface should update the global variable or ztable, in order to restore the data delivery to server X.

Best regards,

Eric

Edited by: Eric Hernandez Pardo on Sep 15, 2011 10:33 PM

Edited by: Eric Hernandez Pardo on Sep 19, 2011 4:44 PM

[Former Member]

Hi all,

I want to share some information that our team is discussing.

u2022 Anyway, just looking at the requirement, one way I would achieve this is as below

o I would create a u2018Zu2019 table in ABAP stack of either PI or ECC (I am assuming your ECC system is involved in this integration)

o In that Z table, I will store the database Au2019s JDBC adapteru2019s communication channel name.

o In the BPM, I will first access this u2018Zu2019 table (you can use the RFC adapter to do this) to get the communication channel name. When the interface runs the first time, it will be for DB u2018Au2019.

o If there are errors in the JDBC, then I will update the Z table with communication channel name of DB u2018Bu2019.

o Then I will proceed to send the interface message to DB u2018Bu2019 within the BPM.

o From that point, the other instances of BPM will send the message to DB u2018Bu2019 because of the Z table entry.

u2022 This is one suggestion I have knowing what you have. Looks sort of complex. Using ccBPM in itself is a performance hog. I would recommend you to consider other options like:

o Do you need two tables?

o Are you doing this because of high availability?

o If yes, may be you should have the same database in a cluster that way PI has to deal with one communication channel only.

Answer:

In fact, a unique requirement, thatu2019s why we wanted to hear some others opinion.

Answering some of your questions:

- After the error has been fixed, there will be a manual switch back from database B to database A

- Yes, within the ccBPM there is a synchronous call which allow to know when there is an error

- Your assumption is correct, we are doing it for high availability reason, mainly because it deals with a critical business process. We understand the performance topics related to ccBPM. At a first though, we think the use of ccBPM is justified since the message is splited, transformed and delivered to two destinations u2013 this database and SAP. Giving a second though, maybe we could use receiver determination rules to obtain two receivers, making the split and eliminate or simplify the ccBPM. Weu2019ll analyze this with more detail.

Let me share some of the solutions weu2019ve analyzed:

1. Storing a flag (not the cc name) in Z table of PIu2019s abap stack. We realize it could also be done in ECC, however, also for high-availability we think it is better to do it in PI. This is the approach weu2019re thinking to use, but still need to convince the client that it is the best option.

2. Instead of using a Ztable, use valuemapping and controlling its value programmatically by making calls to a PIu2019s webservice. The advantage of this approach is that you donu2019t leave the Java stack to store values. Personally, I donu2019t like this approach because in my experience, the cache delays some time to update and it is possible that we donu2019t obtain the result that we need. Please let us know your thoughts on this approach.

3. By the use of PIu2019s webservices, check if the Communication channel of database A is active, if it is, try to use it, in case of an error, swith it off also by calling PIu2019s webservices and swith-on the one for database B and use it. This approach seems possible, however, we depend on how the adapter engine work. We are not sure if it will behave as expected. This approach seems to be riskier. Also let us know what you think of this approach.

Any suggestion will be highly apreciated.

Best regards,

Eric