Skip to Content

Accessing R3 with TREX user index_service

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

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

1 Answer

  • Feb 09, 2004 at 01:49 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • 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