The process looks much the same as the first version but some major changes have happened.
TL;DR: The upgrade to this generation will allow you to migrate a much higher number of your integrations without needing special workaround. SAP have done a good job with it. There is still cases where Figaf tool can complement your migration efforts.
SAP went away from a template approach. To migrate you needed to select on template that you could use but it was fixed the elements in each template making it tough to match for real life integration.
Now they are able to generate iFlows based on the ICO content. Here they generate the BPMN model, layout it out and then add the relevant resources to the iFlow.
One of my first ideas when working on migration was to use some templates. We could just create some templates and fill in a message mapping to it. I fast went away from it because there where too many combinations that needed to be filled in. You need a template for all permutations of migration you wanted to support. That is what SAP now also have realized that is needed and required to spend the extra effort on. It is great to get confirmed that your ideas were good, but a frustrating to see SAP copy another of my ideas.
That is why the IFlow generation gives more flexibility. If you define in the code to add a CSV to XML conversion for some cases it will be added in all the iFlows where it is used. There is no need to make anything special around it. You should be able to add new code for it quickly to be able to support different use cases.
Migration process
The process of migration has not changed much. You need to know that the underlying process is changed compared to the flow. You still need to select the PI system and then you can search for ICO based one some filter.
When selecting the patterns you will notice fewer options. You will just have two.
For Async you also have some options for decouple via JMS and Idempotent process to ensure a message is only delivered once.
You can select if you want to include the mapping in the process or as shared objects.
After the iFlow is migrate you see a report of what you should be checking. It could probably be filtered to the relevant objects that you have in the migration. You now have the option to open it directly.
Migrated flows
It does become a pretty large process if you select both validations. In this here is both selected.
- You still need to fill in data in the adapters.
- There is missing data in the CSV to XML (and in most cases this will not work)
- You still need to fill in some data on the different adapters where the data cannot be migrated.
- I have not checked which adapters can be migrated and if you can use a custom adapter for migration.
The mapping part of the process looks like the following.
You get all in the main process and the mapping is move to a separate process. Making it easier to see the mapping flow.
Recipients list/Multiply receivers
One of the more interesting patterns that we started with supporting with how to deal with multiply receivers of messages. Any ICOs have multiply receivers this is now supported in the Recipient List Asynchronous Pattern.
It generates the following with two processes.
In the initial processing there is a content modifier that calculate Xpaths for Receiver and Interface Determination. For each of the pairs it will be added to the flow. Then a Groovy Script creates a document XML document with the receiver. For each receiver the message is send to the JMS with the information about receiver/Interface.
In the second step you have all the receivers in and then based on conditions the message will be send to the different receivers and messages.
If a message failed on the step it is added to the JMS and you can then retry the message. It is pretty smooth and allows you to see the number of messages pr interface.
When migrating this scenario the tool was unable to migrate one of our message mappings. It was not possible to see why. It does work fine when migrating it with Figaf.
This should ideally be migrated to a Pipeline Concept style flow where the same options will be possible. This will enable you to reuse the JMS queues and make a generic monitoring option.
Java mapping
Support for Java mapping. They create a Groovy Script with a wrapper and then just have the old Java mapping in a jar.
A crappy solution because you still have a JAR that is impossible to edit. And if there is used any existing SAP PI functions or Dynamic attributes.
It is better to spend the effort decompile the code and re-implement it in Groovy (Not legal advise). That way you have something that can be maintained.
I would also have suggested that the Groovy script added was from a script collection then it would be a little easier to find iFlows that had that iFlow as a dependency.
The other day we had a customer that needed to migrate a function called something about Base64 decode. It is probably a better option to use the normal base64 decoder function with some of the other default functions instead of running around with too many strange objects.
We will be adding it to the 2410 Release for the Figaf Migration Tool . And then we will add tags to search for the Objects that way you can see if the objects are needed. It is not a recommended approach for migration.
Does Figaf still brings value?
That is one of the big questions to ask for your migration project.
Im biased and I think we have some new options to help with the migration.
Figaf migration may not be the thing you want for all your integrations, but there are going to be migration you have where Figaf will be able to have you days.
I do think we have some features that make it more compelling to use Figaf:
- Faster turnaround for new features. We have been able to add a new feature in the migration in 2 days that allowed customers to continue with their migration without having to go thru SAP Influnce. It means that we will have support for much more long tail solutions.
- We have found that it is a lot of small problems with the migration that can cause problems and require you to spend hours on reworking a integration.
- User experience of Figaf makes it easy to go from your overview to migrating a scenario and remember the settings you had last time. It is also about having persistence about the migration.
- Support for modules migration, once you have migrated a module Figaf allows you to map it to all use cases.
- We have our own Message mapping conversion where we have been adding support for all the long trail problems that you have in your productive integrations.
- We can convert your Function Libraries in to Groovy Script. The Groovy Script is a bit easier to work and update with our Groovy IDE. You also have the option to select using the Function Library objects for each mapping. The flexibility makes it easier to migrate more mappings.
- Customer adapters can be added to fit your needs. If you have a many scenarios using File adapter and it should be migrated to a SFTP you can specify all the parameters you need.
- Tight integration to the testing tool making it faster to get the feedback and find the right approach for the migration. For Pipeline migrations this will save you a lot of time.
- Support natively for Pipeline Concept. Figaf can create all the required artifacts out of the box, allowing you to continue on the migration.
- Figaf have a prettier layout of the generated iFlows.
- Having Figaf as a secondary Migration tool will help you in your migration project for the cases that are not migrated by SAP.
Then there is all the small gaps that you will need that you can either wait for SAP to fix or just use Figaf for.
I think Figaf tool would still pay a role in the migration. It helps to have multiply ways to solve a problem and not spend too much time on reconfiguring all values.
Moreover, having a different way to migrate can simplify the way you are working.
Get started with your migration
Now that SAP’s tool have been improved you can get started with your migration project.
Figaf tool can still be a huge help in your migration project. We even have the Free Figaf Migration Edition that allows you to test the result of the migration.
Then you can use the Figaf tool for testing the migrated scenarios. That way you can ensure that they work as before. It is really easy to fetch messages form the SAP PI system and send them to your migrated iFlows. Then you will hopefully see they produce the same number of messages. Then you have more conference in your solution and you can test differently together with the business.
You also get trial for 10 migrations which will enable you to explore if they migration can simplify your workflow. When you find it saves you time you can license more objects. One of the other area Figaf can help you with in the DevOps process. Here we allow a much better view of your integrations and the transport process and many other useful activities in the development scope. This is where you can reduce the cost of your migration project by making your integration developers more effective.