Does your new purchase require extra resources

/0 Comments/in /by

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

/0 Comments/in , , , /by

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.

SAP XI/PI dualstack to SAP PO/PI single stack migration

/2 Comments/in , /by


Migration from a dual stack SAP PI to a single stack SAP PI/PO system is a big task.

Many organization is at the moment is in the process of migrating It is away to stay agile and be able to use the newest releases and solve the issues the business requires.

There is also some performance reasons to move to a new SAP PO system because it optimized for faster processing of messages and easier maintenance. PO will also allow your users to interact with processes across the platform.

There are two approaches to it.

1) Upgrade the dual stack system to 7.5.
2) Fresh installation of 7.5 single stack

1) Upgrade to 7.5

With 7.5 the ABAP stack is separated out to a new system id. This feature enables you to delete the ABAP stack and giving you a regular 7.5 system.

There is also the option to upgrade and keep the system as a dual stack system. I don’t think it is a good idea because you are stuck with the same infrastructure and have to get away from the dual stack at some point.

The benefits are:

  • That you don’t have to configure a lot of things again.

The challenges are:

  • It will be a big bang implementation, and everything is moved at once. You better hope it will work after you have tested
  • There is a requirement that you only have configured everything with ICO so it is a java only installation.
  • You don’t have any ccBPM or that you can easily convert the processes in the upgrade.
  • It is not a supported upgrade from SAP, but some partners can do with success.
  • Long downtime while the update takes place
  • You have to be migrating from a 7.31 or 7.4 system for this to be an option.
  • It is difficult to perform any support while the operation takes place.

2) Fresh installation of PO

It gives you a fresh start on your development so you can configure the interfaces with the newest approach.
There is migration tool on SAP PO, which will allow you to migrate dual stack flow to ICOs. The tool has some limitations and will not be able to migrate everything.

The benefits are:

  • You can migrate one interface at the time or in batches. So you will not have any downtime and can verify that the new system works.
  • You can check the new adapters work if you are moving from a Seeburger AS2 to SAPs AS2 adapter.
  • You can use the BPMN modeling tool from the beginning of the project.
  • New platform running on newer hardware and operating system.

The downsides are:

  • It takes a lot of time to move everything gradually.
  • There needs to be coordination with partners to make sure that the messages work correctly.
  • You will have two landscapes for a period that you will have to maintain.

Steps in the migration

A migration should consist of the following moving of objects.

1) Perform a proof of concept test to determine if the new system is working as expected. My experience has shown that there are non-critical messages with low volume that can be switched over to see if those work correctly, without risking the test on critical messages. If something is wrong with the process it is possible to do later.
2) Migrate the high-volume elements and continue to monitor how the migration is working. You want to be sure that your new system can handle the workload; although hopefully, it should be easier to get the same number of messages processed.
3) Move on to the critical interfaces. Now you have a proven system and you can move critical interfaces and make them run better on the new system.
4) Migrate the remaining interfaces. This is the part that can take a long time, especially if you have interfaces that run once a month or less.
5) If the business has requested any change to their existing interface, now is a good time to migrate those interfaces as well, since it will need to be done at some point anyhow. This also makes for a cleaner migration because you will have only one place where development needs to be done. If it involves three parties that will need to make changes, then it is best to migrate it all at the same time.

 

Testing

For both points, there are some challenges with the testing. You don’t want to test too much with the business. Business people often don’t care about such migration because it will not give them new ways to reach out to their customers.

There have been reported some changes in how adapters or message mappings work. They are not a big difference but if your application is using some of the features affect it can have a serious impact on your business.

You will need to ensure that messages processed will not be any different once they are processed on the new system. It can take some time but if you can perform it automatically, then you are far ahead.
There is the Integration Regression Tool from Figaf that allows you to easily test SAP PI/PO integrations. It does take some effort in getting up an run, but it will enable you to test better and with a lot more documents. It will also allow you to install patches more often and ensure your system is on the latest release.

Seeburger to B2B add-on

I wanted to have a full section on seeburger. Because it is one of the technologies that are going away. If you are using it it does have an enormous impact on your business.

If you are using Seeburger EDI converter or tools there may be quite a bit of extra work you will need to migrate.
Last time I checked Seeburger does not support on 7.5, so you will have to migrate all your Seeburger tools to SAP B2B add-on in the process. Even if Seeburger supported 7.5 it would still make sense to migrate because B2B Add-on has more features and can simplify your landscape.

The adapters are configured differently, so you will have to learn how to use the B2B Add-on adapters instead of the Seeburger version. There are some differences, so it is not possible to do an automated conversion of them. For instance is AS2 Partner number on the B2B Add-on adapter where seeburger is using the attribute from the parties selected.

For EDI handling there is also some differences.
For the EDIFACT, X12 messages the XSD structures is a little different, because some elements have been renamed and changed position. Users will, therefore, have to remap the two structures. This change can be done in different ways:

  • Create a XSL(T)/Message mapping that can convert between the seeburger and b2b addon message. That way you can continue using your existing mappings. It will cost some runtime performance to do the conversion between the formats.
  • Remap the message mapping to follow the new format. Repository helps with this. It will experience say it takes around 1 hour pr message.
  • Remap using a tool like SMT from figaf. This does the smae as you would do in the repository but just automated. For more information see https://figaf.com/tools/seeburger-migration-tool/

The inbound processing of the EDI document is also different. You can use one connection for all inbound document because you can use the Trading Partner Management (TPM) to customize each partner.

The TPM many also enable you to restart all mapping all your messages so they follow the newest conversion. It is a big task but may simplify maintenance of your documents.

See also
https://blogs.sap.com/2016/04/06/b2b-addon-compared-with-seeburger/

Get more information about migration

Happy migration

 

Testing async/sync sync/async bridges in SAP PI

/0 Comments/in , , /by

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

Building a business case for testing SAP PI/PO interfaces

/0 Comments/in /by

For any business investment you must to is to build a business case so you can show a positive ROI. Otherwise, money can spend on something else that has a better output.

The same applies if you want to get a better SAP PI/PO testing up and running. And all of my customers of Integration Regression Tool(IRT) must go thru this process. Therefore I thought about helping them out, so you don’t have to start from scratch.

I have created an Excel document with the business case you can find it there.

There are obviously a lot of assumptions that I have made in it. The assumptions are for a medium SAP PI/PO customer based on my experiences. I have tried to explain them in the video that I have made.

In this case, normal usage of testing would cost around 80.000 EUR a year.
If you go for IRT the first year, it will only cost around 40.000 EUR. The second year would be even better because you have made all the initial investment in the testing.
I was trying to see whether you really should be testing. This part had some nasty consequences like have system or factory down for 2 hours or losing a relationship with a customer. Here the price was 85.000 EUR. It had big fluctuations if you depending on how if your system was down every year or every second year.

Do let me know in the comments if there are ways this can be improved.