We continue to invest in making migrations better to be able to help you with your migration efforts. We can make your migration much faster with our technology where we generate iFlows, so you can save time on your migrations.
Last month we added an option to filter specific receivers and keep reuse the migrated objects so you don’t need to manage it twice.
This release we are working on splitting up the process, so it matches more with what you expect from a integration process with local processes. When you migrate you can select classical or our new beta mode.
Before we create fully routed flows but all within one integration process. It does have a few challenges with reprocessing and how to monitor the flow.
Take a look at the different flows you can generate now with this new development.
New process for handling iFlows
With the new process we split iflow into multiply local processes. This makes it a lot easier to reuse and build robust. One individual message can fail without it impacts all the other flows.
A split will be performed if there are multiply Receivers or Receiver Interfaces.
We will also add information about Sender and Receiver interface.
It will also enable you to add an JMS profile for sending messages that is not delivered. So only messages that fails will be added to the JMS. This free up some space in the processing.
Before:
After:
For it to work you will need to deploy a Script Collection on your system see more here. If you have our pi to cpi migration templates please update them to latest release.
We do have a few improvements options here but would really like to hear your input on how to improve the process. We have proven we can create any iflow based on the input. There is probably a few issues we need to improve in the iFlows.
I can see a lot of new features where you can define your own templates for flow or the ability to take existing iFlows and convert them to processing.
On thing I that I did not take into account is the Integration Suite only has 30 JMS queues and 150 Producers/Consumers. It mean that we need to move some persisting to a shared iflow to resent messages or convert to use Datastore. For now it will be pretty easy to use to create manually or it will probably be an option in a future release.
I look forward to hearing your feedback.
Try this new release in the Figaf DevOps Suite, Migration Edition
The best way to quickly see how this new release works is to try out the Figaf DevOps Suite, Migration Edition.
This new release continues to make Figaf the best option for handling your migration and if you are ready to try the new release, start with the Figaf Migration Edition here.
Other
Report over changes to the changes to Channels as a part of modules addition. If you want to test an ICO that requires Figaf to add modules to a Communication Channel. Figaf will now log this and allow you to export a log of the changes. So you know when an Channels has been exported.
If you have a Cloud Integration Test case you can now rerun it and go to the new test run with just one click. This speeds up the normal workflows for testing integration.