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.

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


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/

Happy migration