IRT 1.4 Testing big messages in SAP PI/PO

You asked for it. Or our customers asked for it so now we have created it. IRT, our tool to make SAP PI/PO testing easy, has now been upgraded.

I created the following video

We had a customer that requested that we could process 400Mb messages and verify that they worked. We found that the messages about 10Mb were stuck, so we had to find a way around it. The JMS queue we are using, the build into SAP PI/PO has some limits for external clients. So we try to ZIP the payload, and if that is not enough, we save the message in the database on the agent. We can then fetch the message with a web service call later.
The comparison algorithms were using a lot of memory, so we had to refactor them to be able to compare bigger files. For comparing two 1Mb Text documents, it was using 100Mb, so that did not scale. Now the comparison algorithm has been updated to support messages of 200Mb depending on the hardware. Let’s see if the bigger also works with the memory consumption. If the compare fails it will only be on your development system, so no real problem.
We still have one improvement on the UI to show the big files, but it will come in one of the next releases. For now, you can see it in the Excel reports.

The other improvement was about creating unique numbers in each message. Here we are leveraging the option to use the number range module from the B2B Add-on because it enables good flexibility.

Learn more on how you can test your SAP PI/PO better https://figaf.com/irt

Does your new purchase require extra resources

I want to share an observation that I’ve had while working with some of my customers. Whenever a business gets a new type of product, it often involves integrating a different component into their IT system. In the SAP integration world, there are a lot of new tools that you may want to add, which will need to be mixed in with your existing applications. Until recently, you have probably had only one ERP system, but now we’re starting to see a lot more systems — both cloud-based and integration tools, that need to be dealt with. And the question is, who is supposed to be maintaining these systems?

In my experience with customers, I’m not being called in because their in-house developers don’t have enough to do, I’m being hired because they have enough work already, and now the organizations are trying to figure out how to integrate new tools into their system while maintaining the current workload. Most of the time, there is a new tool that needs to be implemented, and people think that their developers should be able to continue doing what they’ve always done, plus magically deal with this new shiny object! But that’s not always how it works.

If you’ve been in this situation, and your organization has worked to implement new tools on top of the regular workload, please feel free to post about it in the comments.

Most of the time, organizations call in consultants to help figure out how to use a new tool, although it seems a bit strange to me that they would bring in someone from the outside to help, when it is the internal developers who know how the system works and who need to be able to maintain it.

About five years ago, one of my clients had only one developer maintaining all their integration work; but today, they have a team of four or more developers working full time to maintain their system, keeping the tasks up to date, etc. There are always challenges with more complex tools and new needs from the business that need to be considered and integrated. For example, if you’re getting API Management from SAP, you might logically think this is integration work, and would be aligned with the Integration Department. However, API Management is a different tool with a different skillset and a different kind of expertise required to make it work right. Consequently, departments need to carefully consider how this new component will work with existing components, and who is best suited to do the development and integration work of the new tool. Careful planning is needed to understand how you can best tie all the pieces together.

I have to put in a plug here: my company, Figaf, has a product called the IRT which we have created for testing PI systems. It is a new tool built to work with tools you already have. IRT is used in testing to help you figure out where new tools will best fit in and work together with your existing systems, and hopefully save you time and effort.

So, if you’re considering buying a new tool, please take the time to consider whether you need more people involved than the normal integration team so that the tool can be integrated into your current system in the best way possible

SAP PI/PO change tracking tool is now free

I love getting ideas on how to easier to complete a boring task for SAP PI/PO developers.
I believe quite a few of you remembered the PIDocumenter that I created ten years ago. It was a PHP application that could generate an Excel document with the mapping. This function is now standard with Netweaver Developer Studio, though I would say my version was better formatted. That solution became deprecated because the method to get the XMI file was blocked.
One and a half year ago I started working on a tool to make the testing easier on SAP PI/PO. One of the functions we had could make a comparison of XML documents and read the directory API to understand the landscape. It would be simple to combine the two function to compare a directory comparison function.

I have been working at different places where there was a requirement to document what was transported. And I thought it was difficult(too manual) and time-consuming. But there was not a system in place to handle it so things could be changed so it was out of sync. So I wanted to make a tool that could help in the process.

It became the Change Tracking Tool(CTT).

CTT is a tool that will allow you to find what is changed on any objects, like which switch is changed.
In the Swing tool or NWDS, you can see the different versions of an object. It is though difficult to see which specific field was changed in a change. That is one of the use cases CTT helps with.

The other problem is about registering which change is affecting which objects. This way you can have an easy overview of the changes that are happening in your landscape. So you can register the changes on your change number, so you can easily track the changes together with what happened.

It has was given as a bonus to people buying IRT (Integration Regression Tool). It did though not match which what those organizations were looking for. So now you can get it for free. CTT is a part of the installation IRT so once installed you will have access to both functions. IRT is still a licensed product; you can obtain a trial license to try it out.

Take it for a spin and let me know what you think.

Nb. we will add Repository information later this year.

Testing async/sync sync/async bridges in SAP PI

I this week we have added a new functionality for testing your SAP PI/PO interfaces.

IRT is a custom build application that works with SAP PI/PO to make sure you can record messages from your production system and run them on your development system. All with a few clicks in the application.

Watch the video to see more about the application

We got a client request to support async-sync bridges without BPM, and then we added support also for sync-async bridges. The system will then figure out what type of pattern that you are using. Based on the pattern modules and recording will then happen with data.

The other feature is to make sure you can limit the number of test cases you have. For instance, you may have different order types on your orders. And they each follow a different rule set and is mapped differently. If you have recorded 100 messages in total but only 5 for one type and 95 for the other type. You may just want to test with five messages for each, so verify that your interface. Then you can use the new trim functionality to delete all the other 90 test cases, so you just have 5 for each type.

You can get a free 30 day trial at http://figaf.com/irt

Easier configuration of SAP PI/PO test tool IRT

The other day I was going thru the customer journey of my IRT(Integration Regression Tool) application that allows you to test SAP PI/PO interfaces fast.

For my potential customers to see the value in IRT they need to create test cases quickly. There were some steps in the process from them wanting to try IRT to running their first test that could take some time.

The user had to go thru installation where SCA files are deployed on the java system with your favorite deployment tools like SUM, telnet or Netweaver Developer Studio.

Configuration was also one of the points where you had to read the manual to make sure you created users accurate and with roles. It was simple, but if you had not worked with user administration, it could take some time. I wanted to make this much faster and I though of creating a wizard for the full process.

So now you can configure IRT to run you your local system in 2 minutes. I designed it so even my girlfriend would be able to configure it, even though she did not have any experience with SAP user administration.

In the video, I’m also showing how to setup your first test case.

If you want to try it out, you can get a free 30-day trial and test it out on your system.
http://figaf.com/irt