Transport strategies in SAP IdM 8.0

Motivation

Depending on your idm landscape you might have several instances of SAP IdM in your company;

• DEV: Development Server
• QM: Test Server
• PROD: Productive Server

Transporting artifacts from one server to the another was way easier back in SAP IdM 7.2. You selected the changes in the source system and exported them into mcc files, then imported them in the target machine.

In SAP IdM 8.0 you can’t export single changes, but only whole packages. Therefore you will face a few difficulties, you did not face before. Here I want to show some strategies how to handle the new challenges coming with the package-concept of SAP IdM 8.0.

Scenario

We assume that in our simple scenario, we have a two step landscape consisting of a DEV and a PROD system. Additionally we develop new processes and functionalities for our IdM system on our DEV-Server, test them out and when we think that its production ready, we want to transport them to PROD.

Strategies

There are many different strategies how you want to transport changes between systems. I will show you two of the most used ones (by me) and give you some pros/cons.

Bulk package transport

In this strategy you only transport complete packages from DEV to PROD. When you think, you finished your work, you export your package and import it to PROD, overwriting all the existing logic with your new one.

Pros

• Always synchronized systems
• Easy transportation
  • No need for extensive changetracking
  • Small chance to miss functionalities
• Easy source code versioning
• Realistic scenario in a two-step landscape

Cons

• Needs a detailed package structure (you dont want to have a big package, but many small ones)
• A cylcic development/deployment phase is necessary
  • You will need to finish all your development on a package before transporting
  • No way to transport only part of your developed code
• Too complicated for “quick fixes”
• Dangerous
  • No way to check package differences
  • Overwrites everything, can lead to unwanted changes

Transport units

In contrary to the bulk package transport, you might also mimic transport units by creating a transport package. After your development, you move all your jobs/tasks/scripts to this package, transport it to PROD, move them back into the desired packages and then delete the transport package in both systems.

Pros

• Easy way to transport small changes
  • small bugfixes
• Better control of the transportation process
  • you can transport part of your developed code
  • no automatic/uncontrolled overwrites in PROD
• Good solution when you have big packages (like directly after the upgrade from 7.2 to 8.0)

Cons

• Your packages between DEV and PROD will get unsynchronized over time
  • the bigger the differences in the system, the more unreliable are the tests you will do
• Needs a very detailed changetracking
  • You do not want to miss dependencies
• Needs excessive testing
  • three step landscape is necessary here!

Conclusion

It is hard to give you the _best_ strategy, because depending on your situation/your conditions a specific strategy might fit better/worse for your system.

In general you should always prefer the bulk package transport, it’s the only way to keep your systems clean and synchronized. It might not sound like a big problem, but unsynced systems will have a big impact for your work; the more differences there are between two systems, the more unreliable your tests/your further development will get.

In both strategies, a good documentation / changetracking is very essential and will decide how good your transportation will work out for your company.

How do you transport? Do you have a different approach? Let’s discuss!