This is probably one of the larger releases with a lot of new features around the full integration platform.
It feels like all of 2024 has been spent on major upgrades of the Figaf tools platform dependency. We first upgraded to Java 17. Then I June release we only used Java 17. Now we have upgrade all the Spring, Camel dependency to the latest version. It will have ZERO business value. The only thing is we have the latest libraries used and if there is a security problem we can much faster upgrade it. We may now start using some of the new functions but it is not like we miss a lot.
We have seen customers running Figaf on Java 23 without any reported problems, but it is not our supported version.
There are a lot of bug fixes(improvments) and also making it easier to use the configuration. We have also change some of the license flows to ensure compliance with our license model. We added a requirement to have a Git license to use the Groovy/XSLT editor as it was under our development initiative. Test cases licensing is now only on iFlow name. You don’t need to use the landscape for testing it.
Updating notes
If you are using H2 (built in) Database you need to migrate see.
It’s required to process forcible synchronization (options Synchronize objects forcibly and Rebuild links for the latest versions forcibly) of All registries for CPI agents from CTT page to update migration vendor information for the IFlows, update linking between Partner Directory objects and CPI IFlows, update linking between Partner Directory objects.
Edge Integration Cell
We finally got our Edge Integration Cell working. And that means we can start adding support for it in for it.
You can configure it on the Integration Suite agent, what are the different scenarios you have.
You can deploy iFlows to a given integration engine.
You can monitor the edge looks like the standard flows for monitoring in Figaf. There are some limitations like persist messages and other we dont yet have a good way to fetch via the API.
What is coming in the future:
- Testing on the Edge Integration Cell to see how messages is processed.
- Alerting that will allow you to get information about and route errors to the person that can process it.
There are a few limitations because it is different API(Well there are no API), but we have tried to make it as easy as possible for the user.
We have started the journey on the platform, we will like to get your input on what is going on and how we can improve the support around it.
Cloud Integration Tenant report
One thing I was missing was a good overview of my Integration Suite tenant. We had all the data inside the tool.
So now you can generate a report of all the items in your Tenant.
It contains:
- Name and Package
- Versions and deployment status
- Endpoints
- Connections via dependency and connection like process direct
- Usage of Security artifacts
- External Configuration
- Tags about what a given iFlow is used for
We will be enhancing the report based on your input.
You can see a sample section of the report here.
PI to Cloud Integration Migrations
There are multiple objects that have been added to make the migration process easier.
Insert Operation mapping in to flow
We have seen customers have their own flow of SAP Integration where they wanted to insert some of the mappings we have migrated. We do perform our migration in a different way to make it easier to work with.
The mappings will create one or two Local processes with Request and the Response mapping. It also includes all the wiring and configuration of parameters needed. Once you add it to your template process.
Support polling adapters
We have added support for polling adapters in the migration. This is the REST Polling and the JDBC.
You can also test the scenarios with the setup, here Figaf will mock the end points to ensure it looks correctly.
The default is configured as Run Once, which is good for testing that it works. Then you can always schedule it as it is supposed to.
The JDBC may have some challenges since the XML is created differently.
You can also configure some of this polling with your own customer alerting.
Migration of test cases
You now have the option of defining the place where a message should be send in. This is the case if you inheritance have an iFlow that can be triggered with multiply endpoints. Now you can define which once to take.
Add migration of Java mapping
If you have used a Java mapping in an Operation Mapping it is now possible to migrate it. We have taken the same approach as SAP and just reused their Groovy Script and made a few modifications to it. The scripts then calls your java mapping.
There are many limitations like you should not use any SAP PI specific libraries for it to work. The mocking can be extended to support dynamic attributes also.
The correct way is to use some standard functions or to get the java code and implement it to Groovy.
If you don’t have the java code you can decompile the cases and get the result. Then add it into a Groovy Script. I would strongly recommend this because it will ensure that the code can be maintained.
Figaf Groovy Editor is a great place to work on your Groovy Integration.
Stop using ${body}
We have one place in our code that we used ${in.body} that is not recommend to use anymore so we change it to body. But for now not a problem. Notice we added some tagging rules to find iFlows that uses this and more that have an impact on your Camel 3.14 upgrade.
PI migration report
We have improved our SAP PI/PO migration report. Now you get status about the adapters on both sender and receiver side. This will enable you to quick find the interfaces that are no longer running and you don’t need to spend time on migrating.
The report should be the place you want to check your current SAP PI landscape status.
DevOps for Imported Archives
We have now added full support for the DevOps for Imported archives. It mean that if you use SAPs migration tool you may be able to import Function Libraries that uses Imported Archive artifacts.
It is not possible to use these imported archives in other things than Function Libraries, it would have been nice if you could use them in Groovy scripts. Maybe we have that for future joy.
You can now work on your normal transport path, have approval for it and more. And of cause the dependency or it to ensure your transport is correct.
AI enabled Error resolution
We have all gotten an error on an iFlow and wondered how to resolve it. The original approach have been to use Google and search for it.
Now you can use your Figaf Bot to resolve it. From an error you can now click “Figaf Bot”.
Moreover, then you get a prompt pre filed with the error. Modify it to your needs. Once you re ready press the submit.
Then you can see the resulting response and see how resolve the error.
Remember to enable this you need to enable Figaf Bot in the Configuration and provide an Open AI API key. Notice data is sent directly to Open AI. Figaf Team will not be able to read your queries.
Support rules upgrade to Xpath 2.0
In the support tool an important part is to be able to create rules about when to send certain messages. One of the challenges that we found was how do we use Xpath 2.0 in this. We had a customer that used some rules to only get the error once a message has been retried for 2 days. That is what is possible with the Xpath 2.0 where you can use function.
In fact the application already supported Xpath 2.0 in the tagging tool because it was developed much later.
Pipeline Concept/Partner Directory
As the pipeline concept changed in 1.0.6 we needed to change how we linked Partner Directory Entries. Now they are all linked under the PID (Partner ID) which also make it easier for other types of applications.
This will also make it easier to transport the integrations.
Agent configuration
Our configuration of the agents have been steadily improved over time, with more configuration options. It meant that it had sanded till making it difficult to figure out what was related and what you needed to configure. We have now improved the play out.
This also includes an easier option to parse the JSON Service key to fill in the correct values.
We will try to use this layout in other places. We hope this will make it a bit easier to work on your tasks.
Imported Archives in DevOps
We have added support for Imported Archives in the DevOps part of the tooling. If you have imported Function Libraries that uses Imported Archives they cannot be used.
You cannot use the Imported Archives in your Groovy Scripts, which would make a lot of sense just to use the imported archive as a container for jar. Then management of such dependencies would be better.
Figaf does currently not use this in our migration but you can of cause be used if you use SAPs FL in your migration with Figaf.
We have more, soon
We have been adding a lot more features. They could not make it to the release and ensure we had it tested properly. The list includes
- Deploy/Un-deploy feature for large number of iFlows
- Bigger scope for support of Edge integration Cell including testing and alerting
- Creating transports from QA to your production system and ensure they all contains the right information. You would normally have drip transports from Dev to QA, but transport packages to Production. Here you can now see the full status from your development objects.