SAP wants all clients to migrate to SAP Integration Suite on Cloud Foundry (CF) and preferably to the Integration Suite license of it. Neo does not have an end of life, but CF is where new development will happen first.
There are some good reasons where Cloud Foundry is better
- It is in all Hyperscalers (Google is scheduled in Q4 2021) so it is close to your SAP data in the cloud
- It has a better way of scaling
- Disaster recovery is better
- It is where new features are added first
- The license is handled differently. In my book, the integration suite is really good if you are moving all your integration to it. If you just start out it may be a bit expensive with a basic license. It should be possible to get a pr connection license via partners.
- You need to migrate all your integration and connections.
Steps in your migration
- Plan the migration and your landscape
- Perform technical migration
- Security material
- Perform testing
- Go live
Steps in the migration
Plan the migration and your landscape
You will need to understand how you want your new landscape look like. How many systems do you want in it? The normal is Development, Test, Production.
If you have a small landscape, with few integrations you may consider running a virtual Test system. In the Figaf Tool, we have added automation for virtual landscapes you don’t need to copy and edit iflows manually. See virtual landscape.
You also need to understand which iflows are delivered by SAP. In some cases, they iflows can be used free of charge with the Integration Suite license. So it is probably a good idea to import them again from the Discover part.
It is a good idea to see what is being processed in your production environment so it is easy for you to find the iflows you are using. It does not make sense to migrate all your demo or experiments to CF.
Perform the technical migration
SAP has provides a Postman collection that will allow you to handle the migration you can find it here SAP Note 2937549. It is pretty simple to use it and it will enable you to copy and upload
- Number ranges etc
And you can find the SAP Guide here.
One of the challenges that the SAP migration is missing is the security credentials that you need to use. There is a good workaround solution for it.
Santhosh Kumar Vellingiri has written an iflow that can extract the security artifacts so you can configure them in your landscape. Just remember to delete the IFlow from your CPI Tennant after use.
HTTP endpoints and IP ranges
You can get a DNS endpoint assigned to your CPI tenant. It is probably not a good idea to reuse your existing endpoint unless you know that the change of the DNS would not affect your clients.
If you are going with Integration Suite, it may be beneficial to also add API management as a security layer. It can give some extra level of monitoring and it will make it easier to move next time.
You will need to communicate the endpoints to your systems and partners, together with keys. API management also can provide a better approach for handling the connections.
Users and API keys
The way to maintain technical users is a bit different on the two platforms. In NEO you primarily relied on S-Users for the technical connectivity. In CF you can use API keys.
Once you are creating the API key for each system you can add password to the authentication. Then it will be possible to use the credentials as Basic Authentication Username and Password. It will make it much easier for creating the connection. So username will be the clientkey and password will be the secret.
In that perspective it also makes sense to consider how to handle each system. Do you want to use the ESBMessage Send role or do you want to be using separate roles.
The platform is different and so it does make sense to test that everything works as expected. My guess is that there is not a lot of difference between the two platforms. CF may have some newer options and adapters that are not a part of the NEO.
The parts that need to be tested most are the connections because of the changed URL, authentication, and IP ranges. And of course to make sure that you have created the users correctly.
If you want to perform a full test of how your iflows are working Figaf Testing Tool has some options that make it easy to record messages on your Neo system and rerun those tests on the Cloud Foundry environment. If there is any difference between the two runs you will see the results easily.
After you have tested your new integration you can start the transport to production.
SAP CPI integration suites come with Transport Management and you can also connect it with CTS+ if you want to.
You can also just move each landscape separately. It will depend on how many changes you make to objects in the CF development system. I believe it will be better to transport the data from Development to QA and production. Then you can apply the configuration via the Postman connection and possibly connect the other artifacts used.
The recommended approach is to set up a landscape with the Figaf tool that will enable you to transport the configuration to your production system. Figaf is the easiest way to have approvals, testing and documentation of your SAP Integration.
Now you are ready to go live it is a good idea to continuously be able to switch over the processing to your new CPI CF instance. So take some processes or systems to move in one go. That way it will be possible to see how your systems are working.
If there are any problems you can always roll back to the old Neo for that process.
After you have completed the migration project you can start leveraging other resources on the platform.
Good post about a lot of the technical things about setting up the landscape and using the migration tool by Marty McCormick