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.

 

SAPPHIRENOW 2017 from an integration perspective

SAPPHIRENOW and the ASUG annual conference is just around the corner. I’m looking forward to packing my bags and get on the way to the event. To see what is going on in the SAP ecosystem.

I normally do a short preview of the session that I’m planning to attend at the conference so you also can follow along in what is happening. So this blog is about that.

As something new I’ll try to create Facebook live videos from the conference if it possible. I guess there is a lot of things that can go wrong like wifi and location. I’ll give it a try so you can follow along.

I recorded a video on the agenda that I have put together and my thought about it. You can view it here on facebook please comment if there is a session that you think I should add to my agenda.

If you want to meet, I’m planning to see the keynotes at the remote theater DS425. I do hope it is a place where they will stream the keynotes otherwise I may go to find a different location

Here is my list of integration topics. If you are looking at IoT/SAP Leonardo and API there is also many sessions on those. I do hope to be able to attend some of them.   

session

Title

Time

BITI8502

Roundtable: Tackling Your Cloud Integration Challenges

Tue
12:30 p.m. – 01:30 p.m. 

S320 Roundtable Corridor – Roundtable #4

DP44055

Apply the Best Strategies for Cloud Integration

Tue
02:00 p.m. – 02:40 p.m.

Data, Analytics, and Cloud Platform DP532

BA49329

Become a Driving Force for Digital Business with SAP Leonardo IoT

Wed
01:00 p.m. – 01:20 p.m.
Live Business Theater

BITI6663

Best Practices to Migrate from SAP Process Integration 7.1 to SAP Process Orchestration 7.4

Best Practices to Migrate from SAP Process Integration 7.1 to SAP Process Orchestration 7.4

BITI7809

Enterprise Integration Consolidation and Business-to-Business Collaboration with SAP Process Orchestration

Thu
11:00 a.m. – 12:00 p.m.
S310G (South Concourse, Level 3)

Always use PI/PRO for exposing web services

I recently had a long walk at the park trying to get my young son to sleep in his stroller. While I walked, I was thinking about a question I had this week from a potential client, and wondering about SAP integration, and whether or not we need PI/PRO, or if we might be able to use ECC for webshops instead.

The potential clients were doing web service, or a portal, and they wanted to know if they could connect with an ECC backend. I told them that’s fine; the conventional wisdom in PI communities has been that we want to make sure everything is governed through the PI, so we’ve used SOS services. This has been the mantra since I started with PI/XI, it’s been the standard approach.

Recently, however, I see that this standard has loosened up a little, and developers are exposing things in different ways. The first thing that comes to mind is Gateway, which is almost the same thing as using the PI, but enables you to access the ECC data directly using the OData and other similar operations. So Gateway is probably one of the more capable technologies.

We’ve also got solutions like API management, which usually goes through Gateway, or in some instances through PI/PRO. This is a bit of a change, which makes me think again about what the benefits are of using a PI. Obviously, you’ve got the element of governance — you know who’s calling the server – and you’ve got a way of exposing all kinds of different services to the outside world. In this case, the developers just need to worry about web services, and not about RFCs, proxies, or whatever you are calling on the back end. Other benefits include security and scalability, which allow you ensure that that the web service/front end, would not bog down the ECC system with too many requests all at one time. The PI allows you to configure that in different ways. Those are some of the good capabilities of the PI.

On the other hand, the PI is adding some latency to the web service calls, and the development process takes a little bit longer because it is more complicated to call through different layers.

So, ultimately, I guess people need to figure out what a project’s integration strategy is, and whether they have a PI or an HCI, and especially how they all fit in together. For example, if you want an HCI and are calling the ECC back-end, things can become a little complicated! With that in mind, in a lot of instances, it may even be possible to call ECC directly, and let the web guys worry about that part. Sure, as a PI developer, I would prefer to get this extra work, but if it’s not adding a lot of value for my client and it’s just me logging hours, I don’t know if I can justify using it.

What are your thoughts? Please share your input, so I can share with my clients.

The risk pyramid and SAP PI/PRO projects

I took my car to the mechanic recently, and on the wall of the shop I saw a sign that said, ‘We can do two of three things!” On it, there was a graphic of a pyramid with three levels: ‘Low Price’, ‘Short Time’, and ‘Quality’. Then the message, ‘We can do two of these but not three’. Clearly, the idea was that you could have, for instance, a low price and a quick turnaround time, but not good quality.

Project perspective parameters

I think often it’s the same with Integration work. We have these same three parameters when we are working on a project, and we can adjust which parameter takes priority, depending on what our clients prefer to have. Of course, they want all three, but, like the mechanic told me they can’t have all three.

I was presenting Figaf’s integration regression testing tool (IRT) for SAP PI/PRO and one thing that came up was risk of the project.  The thing is, the mechanic’s pyramid is missing the ability to adjust for the very important element of risk. Risk is different from quality — quality is what you get after the project is complete, while risk is a factor you want to mitigate. When we are working on a project, we have risk we want to minimize. In an integration project a risk could be that our mappings will not work with the partners and we need to test more with them. Or that the new technology we try to use does not work. We ask ourselves questions like, how can we complete the project on time? Will it work when we go into production? How many variables are we testing?

I think that a lot of the time, as Integration professionals, we don’t put enough energy into minimizing risk. If you pick up any project management book, one of the big topics it covers is risk. The goal is to teach project managers to ask how they can mitigate and measure the risk they are taking with a given project. Measuring the risk gives the project manager lots of important information that will allow him to lower the risk so that it will be easier to include all the components of a project in less time, with fewer problems and higher quality.

Our SAP regression tool helps achieve all three of the factors in the pyramid by mitigating the risk. First, IRT enables you to set up a certain set of test cases. This reduces risk by ensuring that you’ve run the same test cases every time, and that they’ve passed without any problems. Second, better and more consistent testing raises the quality of the project overall, giving your client a better final product. Then of course, streamlining the testing process reduces the time spent, and allows delivery of the project to the client that much sooner. This is a big deal since most integration professionals work and bill on an hourly basis. And finally, of course, fewer billable hours means a reduced cost to the client.

So, I just wanted to remind you that whenever you are doing integration work, there is a tool that will help you mitigate the risk you’re taking with the project to help you deliver on time and within budget, while still meeting the requirements of your project.

You can check out the Figaf integration regression tool at: http://figaf.com/irt

P.s. We are now going to do a demo of the tool for the client, so they must have linked it.

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?