Accessing R3 with TREX user index_service

[richard_hirsch]

Hi,

Does anyone have an idea or suggestion regarding the usage of the Portal user "index_service" to access R3.

"Index_service" is too long for R3 (max of 12 characters). We need to access R3 to index info using TREX. Unfortunately, I keep getting "Der Aussteller des SSO-Tickets ist nicht authorisiert" errors, which means an SSO error. The user "index_servic" exists in R3 and with a user mapping for the TREX user "index_service" to Portal user "index_servic", I can open a SAP transaction with the SAPApplication Launcher.

Is the creation of an ACL for TREX and its input into the R3 necessary? Or does TREX just use the Portal ACL when it accesses R3 using the various Repisitory managers.

Thanks,

Dick

[KarstenH]

Hi Dick,

what kind of R/3 data are you trying to get to?

If you are coming from EP-KM, actually the preferred method would be to define your R/3 data as a KM repository. This will require developing an according repository manager, though. The API to the repository framework has been published for EP 6.0.

Apart from that, a variety of R/3-based solutions have their own, direct use of TREX (CRM, KW, BW, PLM DMS, etc.) for those you'd only need to place an iView that target their specific search functionality in the portal. You may also want to take a look at MDM (Master Data Management) who will be providing Master Data Searches on TREX basis.

Please let me know a little more about your desired architecture, so I can understand, if this is feasible.

Regards, Karsten

[richard_hirsch]

Hi Karsten,

This question is related to our use of Pilot-Version of the DMS Connector for PLM. The problem was actually related to the fact that our PLM system supports various EP portals. Therefore, I had to create a new ACL with values other than the default values. This is done by changing the login.ticket_issuer, login.ticket_client and login.ticket_dn values in the usermanagement.properties file and then creating a new ACL that can be added to the PM system using STRUSTSSO2 transcation.

This worked great and SSO worked well for users that attempted R3 access using the portal. TREX, however, kept on using an older or the default ACL. I don't know whether it always uses the default ACL values or it copies the portal ACL during installation and then never looks again to see if it has changed. I updated the verify.der in the Windows Directory as well. Still didn't work.

The solution I found was just to use the default ACL. Then SSO access from TREX worked again. Wasn't too happy but it works

Probably a bug ......

When I have time, I might create an OSS Message.

Regards,

Dick