JCo Connection Parameters and Migration through Dev/QA/Prod

[Former Member]

I know its very easy from within XI to open up a JCo connection to an SAP client, but my question is about determining what SAP client to connect to.... and how to migrate that along when you move the XI development from Dev to QA to Prod.

Lets say for example we need to maintain some mapping tables that are much more suited to exist in an R/3 system where users can use SM30 for maintenance (5 lookup fields, default values, ranges, etc), and we will RFC enable that and use in an XI lookup. Since this data is central to any particular R/3 system, we thought about storing this information on the ABAP side of XI itself. What I would want is for my JCo function to know what XI system we are currently on, and then call the ABAP side to use the data through a JCo.

The best that I can think of is using a properties file and maintaining a separate properties file for each system that I'm on, that has the same name (hardcoded in the java where the JCo is???). I can't seem to think of an easier way to do this.

Concerning the use of the Lookup API, I haven't gotten to far into it yet, but for some reason I thought I would have the same problem in there. In examples that I see (for example, Michal K's pdf on RFC lookup, he still hardcodes something in there (i.e. BCS_800) when the channel is defined).

Maybe I'm missing something obvious. Any best practice is much appreciated!

[Former Member]

adding to all the replies about the Lookup API: as i don't like uploading any properties file and then someone forgets and we get qa data in production etc. I thought about creating a BusinessService like "MappingLookup" and creating channels which could point to different systems all for this service. If using a role name in the channel name instead of a system name, we would only need to put Service Name and Channel Name in mapping dev. and can transport the mapping without changes, we just need to make sure, that the service and channels are created with the respective names on all environments.

That's not an ideal solution either, but it's purely XI config, omitting any external files...

Best regards

Christine

[STALANKI]

I was just kidding..:)

I donot require lot of point as I alraedy have..:)

[STALANKI]

Peter,

Can you allot me 10 points if your scenario is answered.

[former_member184154]

Sounds quite <i>bleak</i> asking for points, doesn't it?

I think we all contributed to answer Peter's question. It's up to him to decide who to reward and how much.

[Former Member]

I've done the following in pre SP13 production interfaces:

In a Java Map, or User-defined Function of a Message Map.

- Get the hostname of the XI system.

- Lookup the connection parameters in an imported archive XML file based on this hostname. This file contains connection information for all environments.

- Call the lookup RFC on the XI or R/3 system using JCO.

From SP13 on you can use the lookup API to avoid having to do this. See the following for more information:

http://help.sap.com/saphelp_nw04s/helpdata/en/cf/406642ea59c753e10000000a1550b0/frameset.htm

Thanks,

Jesse

[Former Member]

We exactly did what you described: mapping tables in an R/3 system and access them from XSLT/Java mapping in XI. The tables themselves are in the ABAP stack of XI. And we access it with the Lookup API. Works fine.

When using the Lookup API with RFC/JCo, you still need the name of the "Service without Pary". We have put this name in a properties file on the filesystem of the XI server. The file has the same name (but different contents) on Dev, QA and Production.

We have also used (or abused) the SAP XI value mapping to store configuration parameters in, but are now quite happy with this properties file on disk.

Kind regards, Guy Crets

[STALANKI]

use message mapping and from sender service and reciever services as key for indexing the file and getting the connection parameters..:)

[STALANKI]

You can create file structure in AL11 tcode and put the properties file there and java mapping can access it accordingly!

[former_member184154]

You just answered yourself

In my last project we managed it with a prop file.

Just give it the same name on the three system, keep it in a separate Imported Archive (separate java package as well), load it from java as resource.

Problem comes if you cannot upload objects directly into QA and PRD...

In that case, maybe a prop file on the filesystem is better. Just choose a suitable location existing on the three systems, and you're done.

Regards,

Alex

[Former Member]

So you just put a prop file as an imported archive with the same filename, and maintained the package for whatever XI system you were on, then loaded it up as a resource? I think that I could do this in 1 SWCV and then have others base themselves off of that one so I only have to do it once.

The file system could also work - Problem now is we have our Dev and QA as different system numbers on the same unix box.

Thanks for the quick responses!

[STALANKI]

Peter,

we have the same scenario and we edit the imported archives and we have to re-compile it with the new connection parameters.Iam afraid there is no other way to do.

Otherwise using sender or reciever service we can map the connection parameters and then pass it to JCO calling user defined function.