Migrating ICOs to Integration Suite and testing them with Figaf

In this video, we'll have a look on how you can migrate an ICO into integration suite. So here we have the list of the ICOs. We can see what's been migrated. We can see if we have test cases for it. I want to select the one I just have created a test case on, and this interface here. We can see that it's already migrated a lot of times because it's our test scenario. We can also, if it's from any other one, we just select the error here to the right,

and we get into the migration. But I just want to create it in here and we can select the package that we want to do testing on. I create a new package with no content in. We give the iFlow name training October and then we have a number of profile types. We have a single process And if we press check here, we can see once we press check, it does fetch all the different content that we have in the migration or in the PI system, the ICO, it fetches everything that needs to be used here and it's put into this debugging file. In the debugging file, you can find all the relevant content that is used by this. So if you open a ticket, you can run here and say, yes, give me this detail. if the check fail the main reason we have seen is that the synchronization did not work out smoothly and what you then need to do is you just need to go back to the migration overview here select synchronize select your pi system and select synchronization of the first two here and this will announce to fetch all content again and rebuild all the links because we need these links. So, Figaf needs the links to ensure everything's correct.

We have here also a box we can say where do we want to run it on cloud integration, on SUSE Edge, or its integration systems. They're all listed here. So, if we want to deploy it on certain scenarios, we can select it from here. We can also select whether or not we want to deploy after the migration, how confident we are on this tool works. And then we have here, as we can see this in cloud integration, we have the option that we can see here, use enable cloud connector for this scenario.

We also have some other profiles. So single process, if you do check here, we can see that the process. It's just one message, a router, all the different messages, no error handling. It's probably okay for doing synchronous processing, but you probably want something else. That's why we created local processes. Here, we have the router. So it's then being sent to two different routes, one for each of the different systems, and then we have a common error handling to handle the supporting. And what we can see here is that it goes and delivers this for the different receivers and processes in one transaction. We can use this one. It works pretty well. and then we can say yes we just want to migrate it before we need to do migration we have option here to exclude certain receivers if we want to say yes this receiver is not really ideal we do not need need those we can exclude them a lot of time in pi you would see a duplication of the content that's put into an archive folder those things you want to exclude but also if you have scenarios where there's content that is not really needed for multiple different purposes.

Then we can see all the artifacts that's being used. And here we have all the different artifacts. They have reused shared artifacts. So how this works is that Figaf keeps a copy of this content. And if we open here on a new tab, maybe this will work. The thing is, all of this content here is shared, and this means we can see that this message mapping here is shared between different iFlows because it's being added there. If we go and make a change to this, we can then say, yes, it's not updated in this version, so we can go in and upload it here. So it becomes a way to store these artifacts inside of the Figaf and ensure that they are replicated to the relevant objects. We can see here that there is other artifacts here. There's a B2B mapping kit that's been, that's an XSD schema, but we have some scripts here and we can see here we can reuse these scripts. So we have the reuse, we have overwrite the shared artifacts. So if you want to create a new migration, we can select this option here. Or we can say, hey, use the migrated CPI library. So if we have already migrated into a CPI function library, we can also use those. Or we can even map it individually. So we can say for this script, we want to use the Groovy script. For this one, we want to use the function in this script. So when you do this, consider is the Groovy the right way to do it, or is the shared function library a way to deal with this? Both have some advantages. Groovy scripts are much easier to maintain, especially if you use the Figaf DevOps tool. Then you can easily fix these Groovy scripts. But obviously they need the Figaf management to be updated in all the relevant iFlows where these are being used. And Groovy scripts does not support all values of a queue and also not container variables. The other function libraries is using PI related or Java technology. It works but it's not as flexible and we do not have the same level of ability to support those. Select the one that makes sense for you when you're dealing with this. We can also see here

Select the one that makes sense for you when you're dealing with this. We can also see here a message mapping. We have the option here to extract the content into UDF. We do that because the message mapping, maintaining message mapping UDFs is really difficult. There's a lot of things that goes on. And then lastly here, we can see all the different contexts that needs to be added in this, that these are our tags that has been fired and that have caused some problems, potentially, that we need to check, are these available? And it says also that it's a multicast, we need to do some checks around it. We can then just say, just do our check. So whenever do modification, we need to check it. And I'll just see here, I wanna just use the shared artifact here. So check again and select migrate. So the check we have seen that sometimes if you have really large optics, they create some problems and it takes a long time to do the checks on those. So now we actually migrate the scenario and we have access to it here. We can go in and open it and we can see the content.

So now we actually migrate the scenario and we have access to it here. We can go in and open it and we can see the content. So what we normally recommend is obviously that you check what is going on, what you have here. We can see the directory, the hostname is added, internet explicit, SFTP. All of this has been configured and I think one of the also things you'll see all the externalized parameters. So we have externalized parameters mapped into the message mapping and they also work. So we can save this as a version because this is a split. We need to save it as a version and then we can deploy it again. And what we then need to do is, in the Figaf tool, we then need to say, yes, we want to synchronize this specifically. Because sometimes, at least when you have split, we have a hard time calculating how the method is going to be processed. And the order, therefore, we just need to synchronize it again. And that's all you need to do to do a migration of an ICO.

We also have the other profile here, that's the pipeline all, and it is probably the one you want to be using for most scenarios. So here we have, instead it's called name prefix, ID prefix. It is using a send ID and interface name, a partner ID that's being used. I'm using single XSLT and I think for edge or for pipeline, you want to use a deploy after migration. Otherwise, you easily forget to deploy one of the relevant iFlows. We can then see the content here. A lot of times you would have an iFlow that is or an idoc to some other scenario. Then you probably go and say exclude this because we don't want to have used this multiple times. We don't want to have each using the same iDoc. It just needs to use the standard iDocAdapter in the pipeline concept. Once we do changes up in this, we need to regenerate names, and we can see it generates the names so they match. Here we still have the same IDoc configuration that enables us to map the content we have. And here we then have the names of all the different systems that we also have the exclude option here if we want to. And we can go in and see what all the content that is here. It says here that there's an alternative sender name that is being used in another pipeline. I think that's probably before we press the check. Let's see if it still pops up here. Now it is removed. So after we made the change to change the sender name, it was overwritten and then it works smoothly. So yeah, here you also have the option to select Edge. Right now we do not support the pattern directory on Edge, but it is in progress and will be released soon. So now we can see it creates a lot more objects that we need to look into, both the binary parameter, the alternative partners. And once you do the migration, we do synchronize it. And synchronization means that we fetch the content from the integration suite and uses it.

Here we can see the different artifacts that we have. We have a sender interface name and the receiver there. And these pipelines we can also maintain here in the Figaf. tooling. One thing you probably need to do is on the agent. So this is this demo test. Here on the agent, we have the gate config change tracking. Here on the change tracking, we have enable IDE, enable iflope documentation. We used to have an option here that we can go and see the binary parameters. Here we have the options. We can see them in the pattern directory. And here we can edit it. If we want to do more, we also have our browser where, with the help of AI, we can get replacements and ideas about how to deal with this GroovyScript. And for this, obviously, GroovyScript works precisely the same thing. We can obviously open the iFlow here directly and see, do we need to make changes on this iFlow for this specific scenario?

So once you created this migration, we want to test it. And we already created a test case, so you can find that. And then we need to go and say, yes, migrate test cases. We select the test case we just created. we add it to our to a test suite you probably want to create a test suite for integration suite and we can see here that there is a problem with finding out where do i find the specific message it would be the same thing if you had migrated with as a piece tool or implemented it manually you will then go and say yes in this iFlow we need to fetch the payload So, we need to fetch the payload here in this step. And it's message flow tool that it finds it in, and we just say save. And now we have a test case. It's called a chain test case because the chain, and we can look at it here, the chain contains a sender iFlow where we send in the message and then receiver iFlow where we can fetch the result. And when we then run it, we can then see that this message has been processed and it is sending messages to multiple different systems. We can see some of these are successful. And if we want to look into the details of what's being processed here, we select the Figaf message browser. We can see this one fails. There was an incorrect login FTP. Obviously, that's important because then we can easily go in and identify how do we want to run this scenario, what's going on in this. We probably could change the migration to fetch payloads earlier in the testing chain to ensure that it works easier. So that's what you need to do to test the normal iFlow

So that's what you need to do to test the normal iFlow and we can see we now have a test case over here if we want to test the other one we just say here migrate test cases selected test case added and then we also here need to say where do we fit this and I'll just do it here you can obviously make modifications to it so here probably we'll find the wrong payload because we changed it before it was sent but let's try to run it so we can see here it's executed on and executed sometimes most of the times would be there the same I flow but it's some cases we could see that it is using a different I flow that's specifically if you use file systems etc and now you can see we get a lot of warnings or errors and we look at this and this is probably because we are looking at the payload at the wrong point in the the I iFlow. So, yeah, you need obviously to ensure that the iFlow processes messages correctly, and I guess that's also what we see here, that it does not produce all of the, both of these fail with the same FTP connection problem. So, the last thing we can then do is we can then go and say, yes, we want to change this FTP and there's some changes we need to do here that we can set up. And I guess the idea is, let me just see here, what is it to complain about? Log in incorrect, that it's using the wrong code. The idea is that we can then go and say, yes, we have this. It's this test or this iFlow. We want to make our modifications to it.

Let me just check. Well, yeah. The idea is we want to create a template of this once we got it fixed. So what we will then go and do is say, hey, we go back to our Figaf tool. Under our migration, we have this channel migration template. And once we fix the iFlow, we go on and say, yes, this is our direction. It's a receiver. It is a file. It is a profile type. It's not necessarily needed. Do we need cloud available, a cloud connector available? And the channel, then we'll select a channel that looks like this. So we'll take this one. And then we select the iFlow that we have that's a template so the idea is we can go into our iFlow we can find this ftp once we make the changes generate the template this will fetch all the content that's needed for it and we can see that it has externalized the file name it has a lot of other settings that is not really needed and should not be externalized but we have externalized the ones that makes sense for this. And what we can then see is here, here's the externalized parameters that's being used. And what we can then do is we can go in and say, hey, the FTP host is going to be this one instead. So here we'll go in and say, yes, copy this XSLT, create it. I'll add this full endpoint here. No, this one here. the path because we want to create it as generic as possible once we have done that we can run the template and then what we can then see is that it fetches the content from over here and this is then a way we can customize our template so we ensure that they always produce

the right result if you want to give notifications to people you can look at at creating them them here and then they will just pop up in the bottom of the migration screen where you can see what are these, what is it that either that would be manual action so we can see that you're using XSLT to JSON conversion you need to add that manually. Stuff like that could be added to these scenarios and this would then ensure that whenever you work on this you get much more specific details about how it works on. You can see all of our templates here also. so we added a lot about this one file center here we have a lot about content about how we're using the the edge integration cell if we are using cloud connector stuff like that that's been set up so if you're using that those are good good things to look into just to see how do we specify this precisely. But these templates make it a lot easier for you to run the migration and ensure that it produces a right result first time you try it. I hope you learned a lot about how you can use the tool, how you can migrate test cases, how you can migrate scenarios, and how it can simplify your development process. So try it out and see how it works. Thank you.