How to trigger XI scenario from a SQLServer Database?

[Former Member]

We plan to realize the following scenario -> Database(Receiver System) - XI - RFC/BAPI (Sender system)

What's the best practice/technique to invoke the 'pull' from the SQLserver database ?

The requirement is to realize this as 'on-demand' initiate i.e. trigger the interface from Receiver system only when it needs the data from R/3

Thanks in advance.

Mustafa

[prateek · Accepted solution]

What's the best practice/technique to invoke the 'pull' from the SQLserver database ?

Configure JDBC sender communication channel and agreemnt in XI adn specify the poll interval after which XI should poll the database. This is the standard way how database sender related scenarios are handled in XI.

You may schedule this communication channel to start and stop based on your requirement. This could be done using Planning Availability Times

http://help.sap.com/saphelp_nw04/helpdata/en/45/06bd029da31122e10000000a11466f/frameset.htm

Regards,

Prateek

[Former Member]

Thanks all for your valuable input.

The consensus appears to be -> have separate 'Trigger' table on the DB that XI has JDBC Sender Comm. channel polling against (possibly w/ a column for BAPI name to invoke on R/3)

The BAPI will then send the requested data that would map to the corresponding target JDBC Receiver table.

BTW, is it possible to conveniently/easily send a SOAP message from the DB (through power shell, Java, etc.) that calls an RFC/BAPI instead of using the JDBC Sender ? - this would eliminate XI having to constantly poll against DB 'Trigger' table... please comment. Thanks

[henrique_pinto]

Hi Mustafa,

by all means.

If you can trigger a Web Service from your DB layer, it's much easier.

This web service could even be synchronous and then your application in DB could, once it receives the response from the WS, call a SP to insert/update/delete the tables.

Alternatively, if you can call Java code from the DB layer, you can use Java proxy instead of Web Service (which, in the end, is the same thing. the only difference is that, if you consume the WS in DB, you'll need to create a proxy for it there; if you use java proxy, XI create the proxy in it for you, and you just have to call it's EJB from your java code).

Regards,

Henrique.

[Former Member]

Hi Henrique,

That's awesome ! Can you direct to samples of such things on the forum - I would like to give this a spin but do not where to start...

Thanks,

Mustafa

[henrique_pinto]

you mean how to call a webservice in xi?

just give it a search, there are tons os scenarios (look for soap sender thread/weblogs).

Regards,

Henrique.

[Former Member]

Hi Mustafa

JDBC adapter standard is to poll to DB and it can be controlled as mentioned above. One more method to get data using JDBC sender is let the channel poll to staging tables and when we need XI to pick data we push data to those staging tables.

In real time we faced this situation and came to staging solution to satisfy requirement. BPM hit on performance and so Staging tables with SP etc are performing well.

Database(Receiver System) - XI - RFC/BAPI (Sender system)

My understanding is when you want to pull data you are doing

Database(Sender System) - XI - RFC/BAPI (Receiver system)

Thanks

Gaurav

[Former Member]

Hi,

this could be a solution:

/people/community.user/blog/2006/11/16/step-by-step-realize-your-bpm-scheduling-capability

Regards

Patrick

[henrique_pinto]

JDBC adapter works with pooling intervals.

It will pool from time to time (configurable) for changes in some DB, and when that DB is changed, then it will send the new entries to XI and trigger the relevant scenario.

For your case, I'm not sure which would be the best approach.

Maybe you could populate some dummy table with a "request data" entry whenever you need it.

Then, when XI sees this new request entry, it will trigger an interface. There, you could either call a BPM, lookup data in RFC and call another interface back to DB, or you could try async/sync bridge without BPM, using module adapters, as explained in this thread:

Not too pretty, but might work.

Regards,

Henrique.