Dynamic SAP adapter connection

Hi All,

By any chance any body connected dynamically to SAP system. We have ‘n’ No of SAP systems which will subscibe the same information using BAPI/RFC/IDOC and also these ‘n’ systems will send the data in different ways BAPI/RFC/IDOC. Just we are trying to intract dynamically based on the input insted of having ‘n’ static connections. If any one can provide basic idea it would be grate.

We will create the configuration file and assosiate the with some key input data so that it will retrive the server information, but I am not sure what services I need to use to connect the SAP system.

Thanks in advance.

If you have the right IS version and patches you can dynamically determine which connection to use for a given interaction.

You’d define adapter connections for all SAP R/3 instances. Then using data in the input or some other mechanism to determine which instance you want to connect to, you can specify which $connection to use when invoking a particular adapter service.

Thanks for your reply,
We have a very good wM environement and also we will update patches frequently.

Does it mean I need to have static connection? If this is the case I can manage and leverage my coing but we are to trying to leverage the connections also.


Yes, you’d have a static adapter connection defined for each SAP R/3 instance. But at run-time your code can use any of them dynamically.

Any one tell how to configure adapters in webmethods

Hi Rob,

This implementation we can do using any configuration file, based on the input data we can differentiate the subscribers.

How we can differentiate different publisher to the same subscriber?
ex: A&B are SAP systems they are sending same PO to C system. In this case both A&B are sending via RFC/BAPI, in this case how can I minimize my coding?(A and B data are mapping to PO UDM and Publishing…in these two cases I have to Invoke two BAPI’s…even they defined same name and same structure …Like this we have ‘N’ SAP systems.)

Thanks in advance.

Is there not an identifier of some sort in the data to indicate the source system? Is there a way in the transformation that you can account for the mapping differences without explicitly knowing which system sent the data?


Very interesting discussion. We have a similar situation. For Integration Testing, we have created SAP clients like ECQ 300, ECQ 400 for Round 3 and Round 4 testing respectively. For testing related to Interfaces, we had one set of Legacy (QA environments) connected to the middleware and the middleware in turn connected to SAP. For Round 3, we connected the middleware (webMethods) to ECQ 300, and then for Round 4, we connected the middleware (webMethods) to ECQ 400. However, we want to connect the middleware (webMethods) to both ECQ 300 and ECQ 400 at the same time so that testing could proceed in both clients.

From the discussion above, it seems this is possible by creating static adapter connections for ECQ 300 and ECQ 400 and then defining a parameter or meta data which can be retrieved and code modified to determine whether the data needs to be sent to ECQ 300, or ECQ 400 or both to ECQ 300 and ECQ 400.

Is that correct? Can you provide additional suggestions, insight? Please let me know. Any help on how to use SAP adapter to send and receive data from multiple SAP clients at the same time would be appreciated.


ris, you have the general idea. First you configure your various connections in the SAP admin area. Then typically you browse for SAP RFC calls and generate a stub flow service from the admin. Many people don’t realize that this is a pretty generic service that hardcodes the alias right in the flow. I remove this hardcoded alias name and pass it in as a variable in the pipeline. You can make a wrapper service.

In general it’s not a good idea to connect to different environments from one box (like setting up a connection to prod on the dev box) because of the potential to screw up prod or other scenarios. So IS dev connects to SAP dev, IS test connects to IS test, etc. You use the same alias name so the code doesn’t have to change since the connection parameters are configured in the admin. But it certain cases you have to do what you are proposing. The problem is that the code you write to branch on different aliases shouldn’t be migrated to other environments (test, prod) so it’s only used for temporary testing situations.

Great thread about dynamically setting, or better put, over-ridding the sap connection that an adapter service is initially set to use. The WmSAP 6.5 has the concept of adapter services now. So I have an adapter service that invokes a bapi and it is initally setup to commuicate to SAPA … I have two SAP connections, one for SAPA and other for SAPB. The users guide says to set a parameter called serverName to the sap system you want the service to connect to. I set to SAPB but SAPA is the one that is still called.

Any ideas, insights would be most definitely appreciated.

We are migrating our SAP Adapter from 4.6 to 6.5.

Standard migration script does not seem to work (this was provided with SP1 for SAP Adatper 6.5 !).

So we set out to achieve the daunting task on our own !!
One of the options was the brute force approach where we intended to ‘recreate’ all the RFC/BAPI calls manually. We did set out on this approach.
However, we got stuck with the issue of ‘dynamically’ changing servername at runtime when the adapter service was to be called.
We referred to the SAP AdpaterUsers Guide 6.5 (page 62).The help is very cryptic (or we were dumb not to understand it !)
The documentation says that we can use field called serverName to pass this value dynamically.
We did the following:

  1. Created a test service that calls the Adapter service.
  2. Create a Map step before calling the adapter service. We map the variable serverName to the SAP connection name configured in the SAP Adapter.

On testing the service with different serverName values, we found that the adapter service is being invoked only on the server which was referred during the Adapter Service Creation.

Is there something we are missing !