xMII v12 - JRA Action Blocks Question

[Former Member]

We are implementing v12 (AIX) and require ECC server load balancing for our production environment. Production environment we have multiple xMII servers and multiple ECC servers. (our development environment is standalone, single xMII server, single ECC server). I understand that the JRA action blocks should be used for ECC load balancing instead of the JCO action blocks.

Could not find any information concerning the 3 choices available in the JRA Start Session action block. We do not know which deployed adapter to use.

1. nonGlobalTx/eis

2. shareable/eis

3. unshareable/eis

From a previous post, found the following link, but did not go into detail on the 3 adapter choices:

http://help.sap.com/saphelp_erp2005/helpdata/en/6f/1bd5caa85b11d6b28500508b5d5211/content.htm

[salvatore_castro · Accepted solution]

David,

You are correct going forward the SAP NetWeaver team recommends using JRA for all ECC communication. The load balancing is not a setting in MII but rather configured in the Resource Adapter itself via the Visual Administrator (Services -> Connector Container). If you specify the "Message Server, SystemID, and Group" properties in the configuration and specify the ECC Gateway server this will load balance your requests as shown [here|http://help.sap.com/saphelp_erp2005/helpdata/en/2d/c60242e5216324e10000000a1550b0/content.htm].

I believe that the parameters in the MII action configuration:

1. nonGlobalTx/eis

2. shareable/eis

3. unshareable/eis

are for the type of "Session" you will get from the connection pool.

Hope this helps.

Sam

PS: Poul - What is the JRA Function issue you are referring to?

[Former Member · Accepted solution]

Sam,

We found a bigger issue concerning the JRA connection: the JRA does not have a SAPSSO2Ticket property. With the JCO, we use this property to pass the SAPSSO2Ticket. I put in a SAP Note on the SSO issue and asked about the 3 JRA adapter choices as well.

David

[salvatore_castro · Accepted solution]

Dave,

The reason why SSO isn't available in the JRA actions is because it's a pooled connection resource that would require you to generate new connection pools each time the username changes. I believe that this feature has been added in v12.1 of MII, but this of course doesn't help you at the moment, keep an eye on the v12.0 release notes maybe the enhancement will be rolled back into v12.0.

Sam

PS: You can always enter it into CSS as a feature request for v12.0

[Former Member · Accepted solution]

Sam, in another post named: "Connect to SAP using JRA", it seems Kevin successfully used SSO with JRA. I noticed Kevin never posted the details of his success. Do you know any more concerning his success? It sounds like it is not possible without the xMII 12.1 fix...

Also, what is a CSS and how do you go about entering/submitting one?

Appreciate your help!

David

[salvatore_castro · Accepted solution]

David,

CSS is the SAP Customer Service System where customers can enter in support issues for all SAP Software Products. Start with http://service.sap.com -> SAP Support Portal and go from there.

Can you post the link to the aforementioned thread?

Sam

[Former Member · Accepted solution]

[;

[salvatore_castro · Accepted solution]

David,

I believe that he was able to accomplish this through some of his own custom coding in his J2EE application running on top of Enterprise Portal, but without a reply from him it's tough to say for sure.

Sam

[Former Member · Accepted solution]

Sam,

We were able to get the JRA to function by setting the Userid in the JRA Start Session to the userid available, IllumLoginName (doesn't need the SSO ticket). Can you explain the implications of this in regard to the pooled connections, from your answer above, as opposed to how the connection pooling will differ if used the SSO functionality of xMII 12.1?

David

[Former Member · Accepted solution]

Sam,

Actually found that the JRA UserName can be blank or bogus. So, it must be using the user account that was used to setup/configure the JRA. Will do some more testing.

David

[Former Member · Accepted solution]

Sam,

I changed a transaction that updates SAP orders from JCO to JRA and executed it. It updated SAP with the UserId/UserName that we used to configure the JRA. So, bottom line, this definitely will not work for us. We will have to wait for 12.1. Can you tell me when 12.1 is planned to be released?

Please go into more detail on reasons why recommending JRAs over JCOs ?... "going forward the SAP NetWeaver team recommends using JRA for all ECC communication"

Thanks for your help.

David

[salvatore_castro · Accepted solution]

David,

Just for completeness on the earlier part of the thread here are the connection definitions:

"Non-shareable" - means that inside a transaction 2 or more physical connections will be created if applications wants to acquire 2 or more connections from one resource adapter. Each connection which is acquired from application will use separate physical connection.

"Shareable" - means that inside a transaction 1 physical connection will be created even if the applications wants to acquire 2 or more connections from one resource adapter. All connections that are returned to the application will share one physical connection. This is the default configuration.

Non-global TX - connections which are acquired from connection factory with this setting will not be enlisted into distributed(JTA) transactions. This is SAP specific setting.

Global TX - Connections are enlisted into transaction. This is the default/standard configuration.

As for SSO, I may have misspoken earlier about this still trying to find a good answer for you. In the mean time here's the best that I can do:

Application authorization - application is responsible to provide user/password during get connection request. Or user/password is specified into resource adapter properties. This is the default configuration in SAP.

Container authorization - means that server is responsible to provide user/psw based on specific configuration which is done on the server. For example SSO is done with container authorization.

The Container Authorization has a bunch of SAP Help (

If you

[Former Member · Accepted solution]

Sam,

Thank you for the clarification. btw, the end of your last message was cut off.

David

[salvatore_castro · Accepted solution]

Here's what it was supposed to say...

David,

Just for completeness on the earlier part of the thread here are the connection definitions:

"Non-shareable" - means that inside a transaction 2 or more physical connections will be created if applications wants to acquire 2 or more connections from one resource adapter. Each connection which is acquired from application will use separate physical connection.

"Shareable" - means that inside a transaction 1 physical connection will be created even if the applications wants to acquire 2 or more connections from one resource adapter. All connections that are returned to the application will share one physical connection. This is the default configuration.

Non-global TX - connections which are acquired from connection factory with this setting will not be enlisted into distributed(JTA) transactions. This is SAP specific setting.

Global TX - Connections are enlisted into transaction. This is the default/standard configuration.

As for SSO, I may have misspoken earlier about this still trying to find a good answer for you. In the mean time here's the best that I can do:

Application authorization - application is responsible to provide user/password during get connection request. Or user/password is specified into resource adapter properties. This is the default configuration in SAP.

Container authorization - means that server is responsible to provide user/psw based on specific configuration which is done on the server. For example SSO is done with container authorization.

The Container Authorization has a bunch of SAP Help ([http://help.sap.com|http://help.sap.com]) on the security configuration here:

([https://help.sap.com/javadocs/NW04S/current/jr/index.html|https://help.sap.com/javadocs/NW04S/current/jr/index.html])

I will continue to follow-up on this but if you keep me updated on your progress it will help me along as well.

Sam

[Former Member · Accepted solution]

Sam,

Just to be clear about how our application functions, the users in the shop are able to update SAP orders. Today, we use JCO actions in our xMII transactions, populate the JCO UserName and SSO2Ticket with with a particular users attributes and update the SAP order. In SAP GUI, you can look up the order (CO03) and see the particular user that updated the order (audit trail).

In order to get ECC Load Balancing functionality, we would need to start using JRA instead of JCO. Although, the current version of JRA (in 12.0), does not allow the multiple user SSO functionality (audit trail) as explained above.

From what I understand so far, this type of JRA (multiple user SSO) functionality will not be available until xMII Version 12.1. (Is this what you are checking on?)

Also, see SAP Note: xMII v12 JRA SSO Ticket ( 0000512652/2008 😞

[https://service.sap.com/sap/support/message/E/002007974700005126522008]

I think Davison is telling us that SSO can be configured in the JRA for a single user (the UserId that is used to configure the JRA connection), but not for multiple users as is required for our audit trail?

David

[salvatore_castro · Accepted solution]

Dave,

If you use the AutoBind feature, see help, you can set the JRA session action to use local configuration and link in the username and password (IllumLoginName & IllumLoginPassword) of the logged in user making the request. This should satisfy your audit trail requirements.

JRA SSO will not be available until at least v12.1, no guarantees since it's not released yet.

Hope this helps.

Sam

[Former Member · Accepted solution]

Sam, we do have AutoBind set, but can't seem to get the IllumLoginName and IllumLoginPassword to work with the JRA. We tried numerous ways but made no progress.

We have a transaction using a JRA and it updates just fine with the JRA configured userid/password. Just as an easy test, I then input my userid and password in the JRA Start Session "Configure Object" and checked "Use Local Settings". Tried to execute and got error:

[ERROR]: java.lang.Exception: Could not load JRA Connection:

java.lang.ClassCastException: com.sap.mw.jco.jra.JRA$ConnectionSpecImpl incompatible with com.sap.mw.jco.jra.JRA$ConnectionPropertiesImpl...

[ERROR]: SAPJRAFunction: Connection Is Not Valid

Does the JRA itself need to be configured differently on the server when using the User/Password?

[salvatore_castro · Accepted solution]

Dave,

Are you sure your User has permissions for remote BAPI/RFC access? You can test this with the ERP Interface action block.

Also, did you link in the IllumLoginName and IllumLoginPassword to the Username and Password fields of the Session action?

Sam

[Former Member · Accepted solution]

Sam, yes my userid has proper permissions, works fine with JCO action block.

Tried it both ways. By entering userid and password in the Configure Object and checking Use Local Properties, which should work. Also tried linking in IllumLoginName and IllumLoginPassword in the Link Editor. Also, tried "base64decode()" and "decode()" functions on the password. IllumLoginUserid is populated. Problem is the IllumLoginPassword is not populated.

Thanks,

David

[salvatore_castro · Accepted solution]

Dave,

The password should map directly without any decoding necessary. Can you please tell me what your current release is? The most current release of MII is v12.0.4 and if you are not running this version please update and then retry the scenario. Thanks.

Sam

[Former Member · Accepted solution]

Sam, we are at Version 12.0.4 Build(120).

[salvatore_castro · Accepted solution]

Add in a write file action and write out the values of IllumLoginName and IllumLoginPassword. If password is still blank/not set then please create a CSS ticket indicating your issue so it can be addressed as a bug. Thanks.

Sam

[Former Member · Accepted solution]

Sam, am using an EventLogger, Transaction.IllumLoginUserid is populated properly, Transaction.IllumLoginPassword is blank. I will submit a SAP Note.

Also, in your reply on June 25 above, you described the "Global TX" JRA adapter option (which is the default/standard option). We do not have this option in our JRA Connector Name pulldown as a deployed adapter?

We have only 3 options available:

1. nonGlobalTX

2. shareable

3. unshareable

Should we have "GlobalTX" option?

Thanks

David

[salvatore_castro · Accepted solution]

Dave,

Thanks.

As for the GlobalTX option, AFAIK there are only three valid options for MII communication to ECC via JRA which are the three you have listed. Due to the fact that the other options are not available via a Global JNDI lookup, see the Java EE Spec for more details.

Sam

[Former Member · Accepted solution]

Sam, am using an EventLogger, Transaction.IllumLoginUserid is populated properly, Transaction.IllumLoginPassword is blank. I will submit a SAP Note.

Also, in your reply on June 25 above, you described the "Global TX" JRA adapter option (which is the default/standard option). We do not have this option in our JRA Connector Name pulldown as a deployed adapter?

We have only 3 options available:

1. nonGlobalTX

2. shareable

3. unshareable

Should we have "GlobalTX" option?

Thanks

David

[Former Member]

Hi Sam.

I have created a message, and have been talking to

Eoin Donnelly

SAP Support Consultant (SCM/XMII)

SAP GSC Ireland

And have been talking to Jamie Cawley also. I does not have anything further on this. Going back, what is the difference on the types of sessions, and which one would you go for ?

BR

Poul.

[Former Member]

Hi.

I have also been looking into JRA connection and have the same question.

But another thing, you might be aware of. I have found an error in the JRA action block and it might fail when trying to call a function module. I know, that SAP have solved the problem but I have not seen it included in a patch yet.

BR

Poul.