SAP Integration Landscape and Emerging Complexity

The field of process integration is changing quickly, setting new challenges for Integration professionals, and I think a good understanding of the available tools is key.

When we talk about paradigms in process integration, there have been 3 major phases:

  • Mainframes: Back in the day, most companies had one mainframe or two. The good thing about the mainframe was that it was fairly simple to integrate what were essentially internal programs – even if you had to work across mainframe platforms.
  • Client-server: With the emergence of client-servers and SAP R/3, the number of application servers was growing quickly. Suddenly, as an Integration Department, you had to figure out how to integrate the applications in your landscape so that you could create a new interface. In SAP terms, it may have been a Business Connector or eXchange Infrastructure (XI). You only had one tool to use.
  • The Cloud: Today, cloud integration is the norm, and the goal is to be able to quickly and easily leverage new cloud capabilities from existing development. A couple of examples of existing cloud capabilities are Hybris Cloud for Customer (e-commerce solutions) and SuccessFactor (human capital management).  There are also a number of non-SAP cloud applications. In fact, you most likely have some of them in your landscape already. As the integration expert, your job requires you to make them all play together seamlessly. Some come with prebuild content others you have to create for yourself.

As I said earlier, it used to be that you had integration consolidation that mostly worked in XI/PI. Now, Integration departments are faced with a very different landscape, driven by the need for new integration capabilities, and need to be looking outside of their space at the tools that are already available in other areas of process development. If we understand what’s out there, we can choose the right tool for the job.

I’m talking about tools like the HANA Cloud Platform – integration services (HCP-IS)/HCI, Process Orchestration (PRO), API Management, and Data Services to do bigger data ETL. We’ve also got the Application Integration Framework Overview (AIF), for when you want to do any integration with backend services. There are also SAP Gateway solutions available for exposing OData. Those are the SAP integration technologies that I can think of off the top of my head, other vendors have similar offerings that may be relevant.

I did this exercise with a customer and we spend 6 hours on the different topics and when it did fit into their architecture.

The big problem for the integration manager/architect is that you need to know the tools, and know when it makes sense to use one and how to select one over another. You also need to be able to train your team to use them. As you learn more, you’ll find a lot of overlap between the capabilities of the various tools, and knowing what each one can do will allow you to streamline your process when you have complex situations.

The challenge with all these tools is that it is both labor-intensive and potentially expensive to try them out. Say you have a situation where you want to expose some data to the user. First, you will have to figure out the logic and the capabilities of the various tools to find the best one to combine the elements so your API management will call  PRO or Gateway — to get or expose some data. Then you’ll need to acquire the tools and start using them, in order to really understand where they fit and what you can do with them. Once you get that down, you will need to work out how to leverage the technology internally. So, a lot of work is involved whenever you introduce new technology like this. You also have to keep in mind that you will be paying for licensing to use the tool, even if you don’t end up implementing it.

So as integration experts and enterprise architects, working in a rapidly changing field, we want to do our homework and really understand any tool and how we can leverage it before we place it in our systems.

What is your strategy for landscape integration? How do you cope with training problems?

How the Seeburger Migration Tool Works

 

I can understand that there is a bit of confusion about how our Seeburger Migration Tool works for converting from Seebuger BIC to the B2B Add-on.

I hope this post will make things clearer.

The big problem is that Seeburger’s XML representation of the EDIFACT/XML formats is different from the ones that form the SAP B2B Add-on. The root node is different, and there is a difference in how Groups and some fields names are made. It is therefore a bit of a challenge to move from one format to the other. Below you can see what the SOT tool does.

I have tried to illustrate the process in the following diagram:
How SOT functions

SOT is a small, self-contained web application that runs locally on your own PC. Once installed, you are able to configure which PI system it should use.

The process is the following:

  1. The user selects a Message Mapping from a drop-down list and which External Definition to use for the mapping.
  2. User Presses Fetch and Update.
    1. This will download the Metadata from the mapping.
    2. Find the Seeburger XSD contained in the mapping.
    3. Compare the existing Seeburger format with the B2B Add-on format. It will then know that it needs to convert from /LIST/S_UNB/S_UNH/G_SSG25/S_LIN/D_1082 to /INVOIC96A/M_INVOIC/G_SG25/S_LIN/D_1082. It is using an algorithm for the comparison, so nothing special is required for the different message types and versions.
    4. Go through the mapping metadata and convert all occurrences of the first Xpath to the second.
    5. Alert if there is a difference in the structure that is not accounted for, or if there are other errors.
  3. The user can then select Update. This will upload the new message data to the server, and the mapping will use the new definition.
  4. You will have to open the mapping and save it to make sure it compiles the mapping files.

You will still be able to use the same original mapping; it will just work on the B2B format.

The functions that you use will still be in the mapping, since we are only changing the use of XSD.

If you want to see more, I suggest that you check out the tool page for SOT.

 

new product, support helper to SAP PI/PO/PRO

I’m happy now.

The reason? I’m finally ready to share my newest creation with you! It is something that I have been spending some of my spare time on during the past few months.
Meet my POSupport tool

I have created Figaf POSupport because I saw that a lot of customers were not handling errors well in their SAP PI/PO systems. They had configured the Component-Based Message Alerting and were getting a lot of errors to their mailboxes, but they were not doing anything with them, because it was difficult to process the alerts, to figure out what the alerts were referring to, and to understand why they happened.

SAP Support Tool -POSupport

SAP Support Tool -POSupport

The POSupport tool can help you organize alerts, while assisting you in the processing phase. You can easily define rules with Xpath, which categorizes the alerts that occur. In the rule you have various options:
You can define an email concerning the solution to an issue, which should be sent to the support organization. This rule could be a great place to store your knowledge about the repeated errors that occur.
You can mark the message as canceled, so you don’t have to deal with it anymore
You can re-send messages that had problems caused by adapter errors; the messages will be re-sent every 30 minutes, until they can be processed when the system is up again

You also get a tracking function of the alerts that occur in your system; using the tracking function, you can update the status of the alerts, along with how they are handled.

There is a 30-day free trial that you can download, and get started with. My guess is that it will take you 1 hour to install and configure. It should make you see howPOSupport works.

This is the first version of the tool, so there are still more features that I would like to add. After trying it, you will probably have your own ideas on what it should contain. Please, let me know what you think: what could be improved? What should be added to it? I would like to add some reporting capabilities, so you can get an overview of how well you perform tasks.

I know that a big question you have is related to the cost of the tool. I wanted to keep the price low to get a higher user adoption rate, so the price will be 3000$/2500€. It is not a big investment – just think how many hours you could otherwise be spending on alerts.

I want to get a lot of customers to try this tool, so I can add more functionality. Until the 31st of October, POSupport will be sold at half price.

You can find out more about my POSupport tool, and see video presentations of it at

SAP PI/PO Learning survey is out

The responses to the survey were finally compiled into a comprehensive report. Reading and interpreting people’s answers were enjoyable activities.SAP PI PO learning survey

I am glad that I can announce the availability of this survey – and the availability of its results. The report can be found at this link: http://picourse.com/learningsurvey/

The survey took place in March 2015. The 139 respondents answered questions related to their career in the field of SAP XI/PI/PO development. They let us take a peek into the beginnings of their careers. These professionals were ready to share the details of their SAP learning experiences. Their answers have clearly shown that a true professional never stops evolving.

There are several methods of learning SAP XI/PI/PO. Most people turn to a course in order to receive the basic information they need, and to understand the platform’s characteristics. Of course, these courses can vary greatly. Some choose standard classroom SAP courses, while others opt for online courses. On the other hand, consulting companies prefer organizing in-house courses.

Another method involves a professional collaboration with a mentor. The guidance of a more experienced developer can make a huge difference in the SAP XI/PI/PO learning process. One of the priorities of the survey was establishing whether sharing ideas with fellow developers can greatly influence the learning process.

Another key aspect that was approached by the survey is the amount of time required by a developer to become completely independent as an SAP professional. The survey has shown that most developers feel confident only after a period of 1-2 years. An SAP course might not be enough by itself – there’s always room for improvement and mentorship is a very good approach to acquiring SAP skills.

Another topic was the issue of continuous learning. I found out that ⅔ of developers review their work, one way or another. That’s quite a large number, and it also correlates with the size of the developer’s organization. The bigger your organization, the more likely it is that you review your solutions.

You can get the report on how people have learned SAP PI here:

http://picourse.com/learningsurvey/

 

Forcing the Use of SAP PI/PO

notebook against colour background with images


One of my colleagues has recently approached me with a question: what happens if the customer doesn’t want the use of the PI system for certain scenarios? We usually stick to the idea that communication needs to be done directly through the PI system – but should consultants force the use of PI for every scenario?

 

In a PI scenario there is a pass-through (no mapping) interface at work. One of its requirements is that all connections go through the SAP system. The main advantage of this comes from the fact that monitoring becomes easier. You are able to see what RFC (Remote Function Call) calls are made and what load processes are taking place. If you know everything that is happening, working on the architecture also becomes easier. You also have the ability to execute the reprocessing of failed messages (asynchronous messages).

 

The PI system also makes it easier for clients to execute a call. They can use an SOAP service to call the system and there is no need to use other protocols. Load balancing is also allowed by the PI system, limiting the number of concurrent calls to the back end. In the case of long duration calls, this can make the ERP system less loaded. If several systems are used, it is easiest to use PI and move the processes from this system to multiple other systems.

 

Now let’s discuss the possible drawbacks of the exclusive use of PI. Obviously, a major drawback is the single point of failure. If the PI system is down, nothing works. This can cause some organizational problems. On the flip side, there is only one system that needs to be maintained.

 

Extra development work is also needed – you need to find solutions for various issues and develop new scenarios (this is good news for consultants, who are kept busy). Needless to say, performance RFC threads will put some extra load on the system and costs will rise if all requests are sent through the PI system. You might also have a problem with too many threads running at the same time. If that’s the case, you will need to do some performance tuning. If you need to do some changes in the area of RFC calls, you will find that changing the endpoint is a rather easy task to complete.


When developing, you should be able to tell whether in some cases the same architecture should be used. As a professional, you have to figure out the ideal solution for every situation. You also need to allow businesses to say ‘no’ to use the PI system for some scenarios.

The post Forcing the Use of SAP PI/PO appeared first on SAP PI course.