Best practice approach for connecting many SAP R/3 Systems without CUA

Hello Alexander,

you have the option to reuse a single synchronization project using certain variable sets (i.e. connection parameters and config settings). You are able to create it in Synchronization Editor tool. Please have a look at Target System Synchronization Reference Guide  https://support.oneidentity.com/de-de/technical-documents/identity-manager/8.2.1/target-system-synchronization-reference-guide/26#TOPIC-1795837.

Regards,

   Tino

Hi tlindner,

thank you for this link!

Regards,

Alexander

Hi Alexander,

I was following your question and was hoping for an answer.
The idea suggested to use variable sets works fine for a huge amount of System that share the same Schema.
And now we are close to the problem. I worked for a customer that had hundreds of SAP Clients connected to the OneIdentity Manager. They had basically 3 different Synchronization Projects with a huge number of Variables Sets. That worked quite well for period of time. Unfortunately, the issues started when the schema of one of the connected the SAP Systems changed. The schema update crashed other SAP connection that used the same Sync Project. During the time this issue got worse and worse, and we had to remove those SAP Clients from the Synchronization Project.

Therefore, I suggested to use a dedicated Synchronization Project for each SAP System. I know that might be overdone. But I didn't want to analyse which SAP System shares the same Schema and which SAP System will be upgraded when (and so on).
I don't know if it is written somewhere in the documentation, when you should go for a new Sync Project compared to using Variable Sets. My question would be the following: Do you want to prevent those issues in advance, or do you want to handle those issues when they occur? I don't know if there are other things that should be considered here as well.

BTW: Because the Sync workflow configuration of each Sync Project is (almost) the same, I created DPR Template to make the connection of new SAP System easier for the OPS Team. The transport of changes on a synchronization project is a different story and is even harder when you have several SAP Sync Projects. But even then, there are several different ways on how to do it.

Hope that helps.
Ronny

Hi Alexander,

I was following your question and was hoping for an answer.
The idea suggested to use variable sets works fine for a huge amount of System that share the same Schema.
And now we are close to the problem. I worked for a customer that had hundreds of SAP Clients connected to the OneIdentity Manager. They had basically 3 different Synchronization Projects with a huge number of Variables Sets. That worked quite well for period of time. Unfortunately, the issues started when the schema of one of the connected the SAP Systems changed. The schema update crashed other SAP connection that used the same Sync Project. During the time this issue got worse and worse, and we had to remove those SAP Clients from the Synchronization Project.

Therefore, I suggested to use a dedicated Synchronization Project for each SAP System. I know that might be overdone. But I didn't want to analyse which SAP System shares the same Schema and which SAP System will be upgraded when (and so on).
I don't know if it is written somewhere in the documentation, when you should go for a new Sync Project compared to using Variable Sets. My question would be the following: Do you want to prevent those issues in advance, or do you want to handle those issues when they occur? I don't know if there are other things that should be considered here as well.

BTW: Because the Sync workflow configuration of each Sync Project is (almost) the same, I created DPR Template to make the connection of new SAP System easier for the OPS Team. The transport of changes on a synchronization project is a different story and is even harder when you have several SAP Sync Projects. But even then, there are several different ways on how to do it.

Hope that helps.
Ronny

Hi Ronny,

thank you for sharing your experience. Yeah, that's intense and you don't want to witness that. I will raise this as a potential risk with the customer. If the schema changes in an SAP system, we must be informed of this in good time and it must be clear that this will then entail time expenditure and costs.

Thanks and regards,

Alexander