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

How does Service Oriented Architecture (SOA) relate to the current world-view in SAP integration?

Service Oriented Architecture has undergone some interesting changes over time. It all began with CORBA, or remote procedure calls, and mainframes. Then came SAP, where you could call RFC remotely and build applications.

Later there was a trend toward object-oriented architecture and building applications based on classes. Where the focus was on objects and what to do about them.

Next came service-oriented architecture (SOA), and SAP’s contribution – Enterprise Services–where creating a sales order required certain components and a partner with certain other elements, and it all became a bit of a monster. SAP heavily promoted Enterprise Services, and any developer that needed to create an interface had to support the unwieldy SAP interface. This was challenging for providers to fulfill and for consultants to work with, because it required a lot of special development.

Later, OData emerged that brought a different kind of discovery protocol that allowed application to self discover content. It is different way of creating services and you would not see a common definition of what an order should look like.

Going full circle, lately we are seeing server-less architecture, like Amazon Lambda, for example. Server-less architecture allows developers to build functions that consume varying services, and in turn, applications can be built to leverage those functions. The smart thing, from a deployment perspective, is that you can create these functions to have all the resources you need, allowing you to scale your application in a different way.

Those developers who have been working in the field for a long time, realize these are all basically the same thing with different approaches and packaging, allowing companies to offer some cool features and be competitive.

From an SAP perspective, service oriented architecture is less desirable. Few developers today are using it for these sorts of purposes. Only a few companies are moving all their functionality to the SAP approach, such as Enterprise Services, which does have some more features than an IDOC.

But from a support perspective, it may still be relevant to use SOA. If you’re using IDOC already and are thrilled with it, continue doing that. But if you are going to build new interfaces, consider whether an Enterprise Service might be worth implementing. In SAP S/4, all interfaces are sent with the OData. All interviews are on the table, so that when data is exposed, it’s easy to read from your ECC system or S4 because it’s all OData on HANA services. OData is a protocol where the command is to expose data as web client data, rather than sending a service order and doing back end interactions. One problem with this approach is that it requires a technical function guide to drive it.

In general, people are habit driven, and we don’t want to invest a lot of time in figuring out how new things work. It’s the same with developers who don’t want to spend a lot of time figuring out how to do something in a new way, unless they perceive a clear advantage. I think this human nature is partly why we don’t see more people using Enterprise Services. Perhaps another factor is that Enterprise Services was originally released in small function blocks, which was an obstacle for developers who were reluctant to implement something that only affected a small subset of the business function they were working with.

As a developer there will always be new things and paradigms to consider. People will always say the have tried it, but now it is in a new context with new systems and concepts. So we will have to live with this change.

7 steps to a SAP PI to PO migration

Some time ago I created a webinar about SAP PI to PO migrations. I wanted to use the content and share it because it is quite useful for everybody working on a migration. I can see that it is some of the questions that I got on my latest webinar was also about the process. I do hope that this gives a better understanding of what is happening.

As with all things, there are 7 steps to make a good SAP Migration. So if you are in the process this is the steps that I would recommend that you take. It is assumed that you will migrate to a new system because it will make it easier to migrate a single interface at the time. If things does not work you will always have a backup plan.

The 7 steps are the following:

  1. Goals
  2. Current integrations
  3. Pattern mappings
  4. Resource consumption
  5. Migration phases
  6. Development
  7. Testing

The process should be very iterative because you learn a lot in the process that you can use to migrate other interfaces. I the current integration you are going to map out all your existing interfaces together with what types of pattern they are using. This information will then be used in the migration phase and how it is going you may get input on how the next interfaces can be migrated.

You can view this in two different ways. Either you can watch my Screen recording video of it.

Or view the slides here and download them if you want to be using them.

I have also created a longer article about some of the SAPs you need to consider more in details in the blog SAP XI/PI to PO migration.  It is not the same and the two have a lot in common.

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.