Change the UME source system for AS Java ?

[symon_braunbaer]

Hello,

sorry, but a quick google search didn't return any reasonable results, so I decided to quickly ask...

We have a Java system, which has its UME user store in an ABAP system.
Now our functional guys have asked us to disconnect the Java system and connect it to another

ABAP system, meaning it will use the user store of another ABAP system, usage type ERP.
Is that even possible ? If yes, kindly guide me how exactly to do that...

Thanks a lot !!

[TomXing]

Hi Symon,

Technically it is possible. But just like others said, you'll never get support from SAP by doing this.

You can make sure the validity of guest user defined by ume.login.guest_user.uniqueids.

And then change the ume.persistence.data_source_configuration as well as the RFC Destination.

But if you ever look at the dataSourceConfiguration_abap.xml file, you'll know there's always some data stored on Java side, even though it's an ABAP datasource. There can be inconsistencies when you manually 'redirect' the backend datasource. You might be able to fix them manually, but others can be unexpected. A UME consistency check might able to help a little bit.

The safest way is to install a new Java system, which should not take you very long time.

BR, Tom

[symon_braunbaer]

Hello everybody,

the above error in the screenshot was only a sporadic error, when I tried again, it was OK.

Tom, I agree with you, so, I would perhaps need to rephrase my question. The requirement is to disconnect a Java system from one ABAP system and connect it to another.

If simply changing the RFC destination is not guaranteed to work, then what is the recommended procedure for doing that ? A homogeneous system copy perhaps ?

Kindly advise, as we need to do that next week... Thank you!

[symon_braunbaer]

I installed a new test Java instance and connected its user store to one of our ABAP systems.

Then I have created a new RFC destination: UMEBackendConnection<NewSID>, where <NewSID> is another ABAP system. Afterwards I have modified the RFC destination in server:port/useradmin, as suggested by Rodrigue. Following, I restarted the J2EE instance.

It seems to work, as now I am able to connect with the password from the <NewSID> system.

[TomXing]

Hi Symon,

1. As per note 718383, it's officially impossible to change from ABAP datasource (to any).

2. You can prepare a new Java system, so that it will point to some ABAP datasource during install, or switch from Java to ABAP.

3. If you have to do everything on a Java system that is already connected to ABAP datasource, you're on your own risk. Perhaps it's too difficult to summarize this action to a good document, so that SAP decided to ban it (see my previous reply for reason).

BR, Tom

[symon_braunbaer]

Thank you, Tom! But installing a new system from scratch is too cumbersome, as we have installed additional applications on top of it and many settings and who knows what else was done. I guess that this will take longer than the business can wait.

In that case I will suggest them to either do the unsupported way, which I tested and it worked, or to go all the hassle of redoing everything from scratch!

Many thanks to you and to everybody who supplied helpful answers here!

[rezaejersbo]

Hello,

I have the same scenario, My question is it any documentation about what is SAP's recommendation for UME set up on sap poratl?

Thanks

Reza

[symon_braunbaer]

Hi Reza,

I think that only your business department has to define which system will be the user store

for your portal. Otherwise you'd want to give sufficiently high setting for the maximum number

of parallel connection, depending on your expected user load.

There might be more to it, but this is all I could currently think of. Good luck!

[rezaejersbo]

Hi Symon,

Thanks for reaply. Yes the plan is configure SSO SAML 2.0 bys LDAP server.

Thanks

Reza