Highlights from the Integration Podcast 2018

So, since I made the first episode of the Integration Podcast on February 4., 2018 I have published 29 episodes. There was one podcast that was skipped and delivered later. It has been a really interesting experience trying to understand how to do a podcast, interview people and learn about integration. I think the cool thing about creating the podcast has been the ability to ask really smart people about what they are working with and how they see the future of integration.

In this blog post, I will take a look back on the three episodes I like the most.

Episode 6: How to automate SAP PI/PO testing with Mark Oshifeso from Anadarko Petroleum

The first episode, I would like to mention is called How to automate SAP PI/PO testing with Mark Oshifeso from Anadarko Petroleum and was published February 28., 2018.

In this episode, I had Mark Oshifeso on the show. Mark was one of the first people to use Figaf´s
Integration Regression Tool for SAP PI/PO.

Mark wanted to make it a lot easier to do an upgrade of the SAP PI/PO system, and with the help of
Figaf IRT he was able to do so.

“It´s crazy easy to use”, Mark says.

Episode 24: SAP Integration and API

The second episode which I would like to highlight is called SAP Integration and API and was published Oktober 29., 2018. I did the episode at SAP Teched Barcelona and it was fun to sit down with Harsh.

In this episode, I talked with Harsh Jegadeesan, who is a product manager from SAP. He is responsible for quite a few of the integration as SAP and has a strong presence in SAP progress
to API.

We talked among other things about the following topics:

  • Using API as a way to remove the complexity of your landscape, as the bedsheet you use to throw over
    your bed to cover the mesh.
  • Why is the API different than the Enterprise SOA. One of the differences Harsh mentioned
    was that E-SOA was a waterfall approach whereas the API is a lot more agile. SAP is using
    the same API for UI so they will do a better job understanding them.

Episode 29: SAP Integration with Adam Kiwon

The last episode I would like to take a look at again is called SAP Integration with Adam Kiwon.

In this episode, I had a conversation with Adam Kiwon who is the part of WhitePaper InterfaceDesign. Adam and his team have created different CPI Adapters, content and products
for making SAP PI/PO better. The thing I liked about it was we got a really great conversion going about what was happening in SAP Integration.

In the podcast we talked among other things about the following topics:

  • Migration strategies when it makes sense. And we talk a little about upgrading single stack 7.31
    system and migration to single stack
  • Creating CPI adapters and how they did it
  • How to create CPI content as a partner and the CPI marketplace
  • How Adam sees the need for tools to improve CPI/PI where he has different interface
    monitoring systems
  • Why Adam had proposed to use the Figaf Seeburger tools for migrating to the B2B Add-on
    on a project
  • We talked about some of the training they where working on for the CPI

Highlights from the Figaf Blog 2018

So, I really hope you enjoyed the three podcasts, I had chosen to highlight. If so, you might also like to read this blog post: Highlights from the Figaf Blog 2018.

The future of SAP Integration PI, CPI and how to prepare your self

So yesterday, Tuesday, November 13. 2018, I just hosted a webinar about the key takeaways from SAP Teched and how to implement things based on it. It thinks it was one of my own webinars with most viewers (40). So it is an important topic. I think I missed the Gartner quote that 50% of the development budget will be about integration or something in that line.

When we were starting to see some cloud applications I did not see so many integrations. Lately, I have seen quite a number of a project involving some cloud application. I had seen that SAP would be able to provide some of the content as pre-delivered, but there are going to be so much more than you will need to develop. I just got an email from an SAP customer that they got a tsunami of cloud integration, so it is other areas as well.

Understand where you are going

On the webinar, I do cover how you can understand your own integrations and try to plan what integration you should be doing. I recommend that you take a look at the Integration Solution Advisor – Methodology. It has been updated and I have talked with quite a few architects using it and it gave them a good understanding of what they should be doing.

Roadmap

Then I cover the current state of the SAP PI roadmap, which will affect your existing integration. I do see the CPI on your SAP PI system as a good option to run some of your content. You probably want to start a migration if you are on a dual stack system, I have some resources on how you can do an SAP PI migration project. If you have Seeburger and want to migrate to B2B Add-on I created a webinar on how you can automate the migration. I also recorded a podcast on how a customer did a migration of Seeburger to B2B Add-on.

After you have been going thru your ISA-M you will have some integration patterns that you need new tools for. I’m covering SAP Cloud offerings for integration and their full iPaaS product. I think it would be wise to use the SAP tools first to see if they suit your needs and if not then you can find a better vendor for the solution. SAP will be adding new functions to the Cloud Offering to address the customers needs.

Operations

There is a need to make more integration at a faster pace. And you are probably not able to get more people on your team. So it is about making them as effective as possible. At Figaf we have created solutions to enable the development process to be a little easier from development, documentation, testing and supporting. You can check our tool Figaf IRT that can support the full lifecycle. I think it will help you improve your development of new features, so you will be more flexible and develop things faster.

Next week I’m hosting a webinar where I’ll cover how you can use the Figaf IRT tool to optimize your SAP PI and CPI development process.

 

You can watch the full video here.

 

 

How to make a moderen EDI landscape with SAP S/4 HANA

I had a great talk with an old colleague this Friday. The topic was how to build a new EDI platform.  They did not have any EDI yet on the SAP platform since they used an old platform for it. So they had to start over with SAP as the backend.

I have been doing EDIFACT and X12 implement since I started with SAP XI using the Seeburger tool and lately seen on how to use the B2B Add-on from SAP to handle the EDI part on SAP PO. The tool has a difference in structure and how they work, but they work the same way. The can take some XML and convert it to the EDIFACT/X12 files and the other way. SAPs platform has been focused on how to make it native in SAP PI/PO, where SeeBurger was a new way of the building the platform.

I have created a video that shows some of my questions concerns on the topic of creating EDI with S/4 Hana.

I was starting to talk about the different IDOCs and which EDIFACT documents they referred to. Then we got a talk about they were doing a new S/4 HANA on-premise implementation. S/4 HANA cloud,  which is the premier SAP product, is where all development is going on. There is only a few whitelisted IDOC’s for some scearnios like syncronize data with your existing SAP ERP system and some warehouse. The EDI IDOCs is supposedly not available, so you cannot use them.

Since all development in on S/4 Cloud and the on-premise version will get the updates after a few months/years, there is not going to be any development going on the EDI Idocs. There has probably not been developed much on them over the last 10-15 years. SAP would like to move their customers to the cloud version to make it faster for them, and customers cannot live with out their flexibility. So we will have to see where it will end.

An option was to use the Enterprise Services (E-SOA) that also worked on the process. I have hear about a few organization using it, but it requires a strong leadership and some skills to go use them. Since Enterprise Services is a dead topic now, i guess it does not make sense to focus on it. It seems as it has been inpsiring the new SOAP APIs from SAP so it is not in vain, and you probalby have an easier option to migrate them.

API is a big focus area for SAP for some reasons.

  • In S/4 Cloud you cannot develop so you have to use APIs to extract and use data
  • It is easier to explain APIs to non SAP developers, because they have a common form of documenting
  • You can expose them online and secure them

All the APIs SAP has created is on api.sap.com, which is SAPs API portal.  On the portal, you can find all SAP apis on the different systems and you can easy try them out there. I did find an SOAP service for sending Purchase Orders from S4, but is currently not able to find it. One of the document you can find is the Scope Item 2EJ, which is covering the purchasing process on how to configure it and steps involved in configuration. So it is fairly easy to get started with.

So it is possible to use the APIs to expose the purchase process for EDI.

EDI from the new APIs

So it is possible to create an EDI solution based on the new APIs. Then what does it require.

A good place to start would be to use the Integration Content Advisor, which is SAP way to make the B2B Mapping faster based on Machine Learning. I have not seen or use the tool yet, but it the idea is pretty cool. It could speed up the mapping of data with the EDI formats. It requires you have the Enterprise Edition of SAP Cloud Platform Integration. You can though run the flow on your local PI. The alternative approve is to use the normal EDI Mapping on SAP PI/PO and use the B2B Add-on in connection with the Trading Partner Management (TPM).  If the Content Advisor works it is probably the fasts way to deal with things.

It still brings up the question about is the new APIs strong enough to be able to handle the processing. And how will the errors be resolved since they cannot be handled in BD87.  S/4 will come with AIF (SAP Application Interface Framework) for some scenarios, which is a tool that enable different kinds of error handling and mapping. It may be suited to some of the normal EDI error that you will see like customer try to send an invalid material number or delivery data. It will require some training to enable users to use it. AIF is more powerful soluction then BD87 since it allow you to add rules and validations.

My recommendation would be to give the new interfaces an attempt to get the process working on it. It would give freedom to upgrade to S4 Cloud and just have one interface for the integration process. I would also imagine that the new interfaces is easier to extent or you can make lookups to get information that is missing.

Have you tried the new S4 way of integration and does it work?

How to ensure quality from your SAP consultants

I was talking about the talking about the future of consulting/freelancing at my disruption training. One thing that we got to talk about was recommendations like as on TripAdvisor.

If you are going to hire a consultant or employee (for that matter), you just have to hope that your skills as judging the person are correct. And also their CV is accurate and has the skills to solve your problems. I’m sure there are some are terrific interviewer, but it may be challenging to find the best person for a job.

If you were going to hire me you would make obvious like to see that somebody has said something nice about me. I’m charging a premium rate compared to what is typically requested via requiters.

I have only been hired once where the recruiter asked for references from two previous clients. I’m not sure what is the normal way to be checking what is going on. The way this normally has happened is. I have asked “Hey John, I have a new project going on will you give a reference for me.”
He will then write few words of recommendation. Like “Daniel has been really helpful in our SAP PI project. He has been taking the lead and ensured our systems is update. ”

The problem with such a review is that my clients may like me for the person that I’m and how I’m helping them. The solutions that I’m providing may not be optimal and not live up to the promise that I gave or is telling them. In some cases where I’m helping with skills that are outside their expertise, they will not be able to tell if I did a good job.

There is the third party review as a second approach. Here either I or future clients need to pay another consultant to review the work that I did. He would need same skills as I have to be able to verify what I have done. It would probably to be the most reliable sources of review because it is judging the work.

Though it may have some challenges. How am I suppose to give third party access to what I have done and shown it the best way? In most contracts, I’m not allowed to share confidential data with outsiders. I have made some solutions that are not optimal if you look at them from an end perspective, but there may have been changes during the development that meant we ended up with some crap data.

A solution: Another way could we agree on two rates a normal and one for good work. For the first period, I’m at the standard rate. Then after two-three months, my client get a third party reviewer to go thru the content that I have made. And if it is okay I got the premium rate (paid back for the 3 months) otherwise we go for the normal rate. And the contact may end.
With this latter approach, I’m giving the client some risk reversal to ensure they only pay the premium if I’m really good. And most consultants would be able to wait for it.
The only price for this would be the third party review, which anyway would be an excellent way to ensure that you are making good quality.

I guess the topic of judging Quality will be in a separate post later. Be sure to connect or follow to hear about it.

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.