Posts

Support for you SAP PI/PO development process

I’m pretty thrilled about our latest development of the Figaf IRT tool for SAP Integration.

When I started doing XI 3.0 work I was really frustrated with the way things were documented. It was a really manual process that users needed to follow. The documentation was never updated. Now 14 years later I can see that we got a tool that can help in the cases. We can now help you really document what has changed automatically.

So a month ago I found that we could leverage the tools we had created for the IRT tool to support the full development lifecycle. Today we are releasing the first version of it. It is not perfect and there are some holes but it clearly shows which direction we can do with it. Hopefully, you will also be able to see the benefit of it.

The different steps in the process are the following:

  • Alerts are raised from a PI Message using standard alerting.
    • Create rules for how to handle alerts
  • Perform your development in Repository/NWDS
  • Create a ticket to with a link to the incident
    • Assign the changes to the ticket
    • You can see the differences I the mappings
  • The test is performed to ensure it works
    • Base on the Figaf IRT test tool that allows users to create test case fast based on i.e. production data

I have created a video to show what we are able to do with the tool.

We still have a few things to work with to with making it better and cover more of the development cycle, but it is always better with customer feedback. So if you have any things that would help in your process do let us know.

You can download the tool for free at https://figaf.com/irt

 

 

The future of SAP PI/PO development

SAP PI/PO developer are normally spending a lot of time documenting what they have been making of changes. We want to make the process much simpler for the end to end development. And capture the correct information. Not just information that cannot be used.

We have created a mock prototype of a feature we are working on. We would really appreciate some input about if this fits your organization. Please share a comment or write to dgr@figaf.com

We have the following process.

  • An incident that is triggered by the component based message alerting in SAP PI. You can easily setup rules to handle the different alerts and how to react to them.
  • Then we create a ticket, which is a new concept in the IRT tool. A ticket is what you could refere to as an Incident, Change Request, Service Request or Gap. It can have a list of status like, in development, in testing or done. You will be able to configure the list and if there should be auto numbers or you have the values in a separate helpdesk system. You can create tickets without an incident if it, for instance, is a business requirement
  • The ticket can get PI object assigned. So you can add any PI Repository or Repository object to the ticket, for instance, a message mapping or channel that has been changed for solving the ticket. When you look at a message mapping you can see which ticket it has been assigned to and thereby get information about why something was changed.
  • Testing from the ticket. It is then possible to calculate which Interfaces/ICOs to do testing on. If you are missing some tests you can add them. And then run all the tests.

You can get more information of the future of the tool by signing up for it at http://figaf.com/irt 

I have two videos about the concept. One that features the overall perspective and along with more explanation along the way.

The short direct to the point video

 

The long version with more explanation

You can get more information of the future of the tool by signing up to it at http://figaf.com/irt

IRT 2.2 Release notes Testing of SAP PI, Cloud Integration and Changemanagement

Yesterday we release the IRT 2.2 to make testing even easier. This release contains a lot of new functionality that makes it a lot easier to test your system.

One of our visions is to make an all round change management tool that allow you to find errors, fix them, document the changes, and test it. We have added the first part of this which is to support the change management, this will allow you to document what is going on in the landscape.  So now we have a link form ICO all the way to message mapping. This will allow us to ensure that you test the interfaces before you make any release.

You can see the video for a presentation here.

 

Cloud Integration. We have now added the option to start testing SAP Cloud Integration (CPI aka HCI) . It is made possible by the new option to trace information so we don’t need to make modifications to your iflows to test it. We can do a regression test with the HTTP adapter now, and hopefully will be able to add some more adapters in next release. For other messages, you need to use the baseline testing, where you will be sending the same message again. We will add more functionality to this testing to make it easier to do regression test for all adapters.

Baseline test cases. This is to make integration with Workflow tools like HPE UFT that already creates a set of number of messages to the SAP PI/PO system. So instead of IRT is sending test messages the sending system is creating the messages. The test would then compare that the same messages are sent and compare that they are processed in the same order. This is also a function we are using when testing with SAP Cloud Integration.

Change Tracking Tool. In the change tracking tool we have added the ability to see all repository objects and what is changed. So you can see where in an object it changed, we will add the option also to do a comparison in UDF and Message mapping in a future version. The cool thing is that you now can see where a message mapping is used and in which ICO/iFlows it is used. This will give users the option to run test report that covers the things that have been changed. We still have to add a few links.

 

If you are ready to start testing your SAP PI/PO/CPI solutions better then have a look at the Figaf IRT tool that allow you much better testing.

Migrate from Seeburger to SAP PI B2B Addon webinar

Yesterday I hosted a webinar where we covered how to migrate from Seeburger on SAP PI to B2B Addon on SAP PO.

In the webinar, I covered some of the biggest challenges with migration.

  • How to create a business case for it. This is one of the challenges that I cannot help that much with, the main reason would be to the Seeburger Licensing. I’m unclear what it would mean.
  • How to convert the mappings. The message structures have changed, so you will need to update the schemas. It is not much but you need to do it correctly to ensure nothing is changed.
  • How to get rid of the seeburger User-Defined functions. The B2B Add-on have some different approaches to variables and counters, you probably need to upgrade the mappings to ensure that it works smoothly.
  • How to ensure everything is tested correctly. You don’t want to coordinate a migration with your partners more than necessary. So you just want to move the mappings and then ensure you have tested enough in the process.

I have two products that work to improve such a migration

Seeburger Migration Tool to migrate your mappings from the old format to the new. https://figaf.com/SMT

Figaf SAP PI testing tool IRT  https://figaf.com/IRT

To learn more have a look at the webinar replay.

Or have a look at the slides from the presentation

 

The Goldilocks Zone of Change management for SAP PI

Setting the correct change management procedure can be challenging. You need to capture the right things and not too much.

For one SAP PI/PO client, I just had to do development in Dev, and then move to production to test. I was really uncomfortable doing this.
Another client requires a lot more effort to do the transportations needed. Here is multiple checks and validations to do transports. Here it takes too long time to do something.

That is the reason I believe there is a Goldilocks zone for change management you need to do not too little and not too much.

In many places, people are just trying to implement the same changes that they have to do ERP changes. Which is probably not ideal for transporting SAP PI/PO objects. I have been spending a lot of time making documentation that was not ideal.

In my example where I had to change a field in the XML formats it would be nice if I could mark the changes and then use it. The more manual work you are going to do the more difficult it will be to make the documentation and ensure it is correct. And how do you find it when it is necessary. So at the client, I worked where we had a lot of documentation we could just capture a few lines text about what we had done on the interface. Finding it again would be difficult because how did you find the message mapping information.

 

For SAP PI/PO we are working to improve our Change Tracking tool that allows you to do better change management on your landscape. We have currently been looking at just directory objects, but in the next, release we will also have documentation of repository objects. This will allo you to assign a ticket and a description of why something was changed. You can then see for a message mapping when something was changed in it and why. You can also do an easy comparing between the versions to find the differences.

Read more at http://figaf.com/ctt