Posts

IRT 2.2 Release notes Testing of SAP PI, Cloud Integration and Changemanagement

Yesterday we release the IRT 2.2 to make testing even easier. This release contains a lot of new functionality that makes it a lot easier to test your system.

One of our visions is to make an all round change management tool that allow you to find errors, fix them, document the changes, and test it. We have added the first part of this which is to support the change management, this will allow you to document what is going on in the landscape.  So now we have a link form ICO all the way to message mapping. This will allow us to ensure that you test the interfaces before you make any release.

You can see the video for a presentation here.

 

Cloud Integration. We have now added the option to start testing SAP Cloud Integration (CPI aka HCI) . It is made possible by the new option to trace information so we don’t need to make modifications to your iflows to test it. We can do a regression test with the HTTP adapter now, and hopefully will be able to add some more adapters in next release. For other messages, you need to use the baseline testing, where you will be sending the same message again. We will add more functionality to this testing to make it easier to do regression test for all adapters.

Baseline test cases. This is to make integration with Workflow tools like HPE UFT that already creates a set of number of messages to the SAP PI/PO system. So instead of IRT is sending test messages the sending system is creating the messages. The test would then compare that the same messages are sent and compare that they are processed in the same order. This is also a function we are using when testing with SAP Cloud Integration.

Change Tracking Tool. In the change tracking tool we have added the ability to see all repository objects and what is changed. So you can see where in an object it changed, we will add the option also to do a comparison in UDF and Message mapping in a future version. The cool thing is that you now can see where a message mapping is used and in which ICO/iFlows it is used. This will give users the option to run test report that covers the things that have been changed. We still have to add a few links.

 

If you are ready to start testing your SAP PI/PO/CPI solutions better then have a look at the Figaf IRT tool that allow you much better testing.

How to start from scratch for using SAP PI/PO

If you just purchased SAP PI/PO there is a lot of things to consider. This post will help you in the process of figuring out what is interesting.

The thing is you don’t know too much but it will have the greatest impact on what is set up. So it would be a good idea to have an architecture workshop where you will get all the insight into how you can create a solution that matches what you want to achieve. So it is an ideal time to get help.

I have created a mindmap video where I cover some of the most important things about the process. Watch the video below.

Architeture

A big thing is to get the architecture to match what you want in your organization. There a lot of things to consider like naming conventions and how to create interfaces. This should you would hopefully get a few sample interfaces that show how the things would look and how to monitor them. You should also consider how to make documents required for it both mapping documents if required and documentation.

It may be a good idea to have a secondary consultant to help you in the process that is on your side because you don’t know as much about what you can expect.

 

Testing

Testing is one of the important things in the process. If you “just” replace middle where you have the ability to get input and output document. If you use the Figaf IRT for SAP PI/PO testing then you will be able to perform the tests to verify that messages look identical. This way you can save some time for testing the application together with business experts.

If are doing a greenfield implementation of SAP S/4 ERP then you will have to change the interfaces on both sides. You will still have to setup testing so you can ensure that the process works correctly even when you have to apply support packs.

Migration

A good place to start is also my migration guide. It is much the same things, except that you have more free hands with what you want to do and the changes that you must make.

There are some of the things here that can be applied to the list of attributes to collect from each interface. You can find it in the slides. If you can get the information it may be a lot easier for a partner to do a good estimation of the project. You may add data like a number of fields in each interface to give better information about required mapping size maybe group it in to bucket like 1-20 , 20-100, 100+ fields that need to be mapped.

Cloud world

In this blog, we have not been covering any of the SAP platforms that may be interesting and save some time on integration. There is the SAP Cloud Platform Integration (CPI aka HCI) which is a solution that is quite simply to PI but cloud-based and more flexible. It contains a lot of prebuild content that will speed up and integration, so it may be used in some scenarios. You may also be able to run this type of interfaces on your new SAP PO system. For some integrations, it may be beneficial to use because of the flexibility and the availability of adapters.

Other advice:

I ask the question what people would like to have known before they started on the SAP PI/PO project a long time ago and I did get some interesting answers that may be quite in line with what you are looking for. There was a lot of ideas about making better guides for what should be implemented. You can read all suggestion here.

 

Good luck on your new platform. I promise it will be an adventure. 

SAP Cloud Platform Integration Day 2017 (aka third annual HCI Day )

I attended the SAP Cloud Platform Integration(HCI) day this week.

I created a video around the topic where I’m going deeper into the content that I can describe here.

 

There is a problem with the name of the product. There is no official abbreviation of it so during the presentation it was mentioned as HCI, SCP Integration and CPI. CPI is the most logical but is used by another product. The lack will mean it becomes more difficult to find people with the correct skillsets because there is so many different solutions. So until somebody find an official abbreviation I’ll be using HCI.

There was a section with the news highlights of HCI where Udo Paltzer was presenting some new.

·        Self service key store

·        JMS Queues internally to decouple async message. It is on the enterprise version.

·        99.99% uptime on a monthly basis. Somebody was mentioning that contract giving SAP access to hours of service window if it was planned.

·        Web UI was the way forward, Eclipse would be depreciated.

·        A customer regression testing solution. Since it is something I’m quite interested in with my tool for doing the same on SAP PI/PO. Check out http://figaf.com/irt to learn about the generic solution to test SAP PI/PO.

Customer regression testing is a service SAP provides where a customer can submit an iFlow together with in and out test messages. SAP would then make a test mock of the service and run the tests on it.

SAP will then run those mock iFlows in their own system before the code is released for customers and if there are any errors they would ensure that they do not break any functionality. This is a service you need to buy at SAP and will only cover your most critical or complex scenarios. And if your iFlow changes you will need to submit new tests. It will be a service you will see on the price list.

SAP was also presenting some of their services that used the HCI. There was a Ariba Connector hub something which enabled you to onboard vendors or suppliers fairly easy. Here the user was guided thru a wizard about the integration. There was some confusion where it fitted in but they were just creating iflow based on the configuration. There was also a Farma net demo where they also created iFlows in the background using some internal APIs for HCI. The API will be public this fall.

I was at a workshop last summer in Waldorf where we were looking for better ways to improve the integration experience. One of the ideas was this one click or wizard approach to create integrations.

There was also a Successfactor and eDocuments presentations. From them it was clear to see that these services gave companies an approach to SAP HCI and then they would get to know the product. And hopefully start moving more integrations to it. The hot example is the Spanish SII document that will start 1 july 2017. Last weeks there was 80 productive instances running now there was 280. So it was a big driver for getting HCI to customers.

There was 9 partner presentations of different levels of depth and relevance to HCI.

Some of the takeways I got from Morten Wittrock from KMD was that it would be beneficial to learn about the Camel framework and groovy scripts because it enabled you to leverage the full platform.

ProXcellence was talking about if customers was really ready for the cloud. It was something to buy HCI but not all organizations was able to leverage it together with the changed capabilities of the cloud infrastructure. HCI was quite simple but you sometimes needed to get some more experienced developers onboard because there were limitations to what business uses knew about certificates and the integration.

Do check out video attached to this post.

 

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?