Posts

Latest Figaf IRT tool and Roadmap

Updated 2018-06-03

With the newest release of Figaf IRT tool, we have been adding a lot of new functionality.

In this presentation, you will see how to test SAP PI/PO and SAP Cloud Integration.

  • The testing of SAP PI/PO is stable for collecting and getting test messages. It is fast to record messages for testing and running them is also fast.
  • Testing SAP Cloud Platform Integration is possible
  • Development Supporting is now in the system that allows you to create tickets and assign any object version to it.
  • Change Tracking now have a deep comparison of Repository Objects so you can see what is changed with a message mapping and contains a link so you can see the affected ICO, that should be tested.
  • Support tool to monitor errors in the SAP PI CMBA and setup triggers for it.

In the current roadmap, we have the ability to fetch test data on SAP PI/PO without installing a module. And to perform object change and the support on Cloud Integration.

Everything has been build into one application that allows users to develop faster and have better tracking of what will happen.

You can start a free trial of the IRT tool by going to https://figaf.com/irt

If you have any questions please reach out to us.

 

 

The future of SAP PI/PO development

SAP PI/PO developer are normally spending a lot of time documenting what they have been making of changes. We want to make the process much simpler for the end to end development. And capture the correct information. Not just information that cannot be used.

We have created a mock prototype of a feature we are working on. We would really appreciate some input about if this fits your organization. Please share a comment or write to dgr@figaf.com

We have the following process.

  • An incident that is triggered by the component based message alerting in SAP PI. You can easily setup rules to handle the different alerts and how to react to them.
  • Then we create a ticket, which is a new concept in the IRT tool. A ticket is what you could refere to as an Incident, Change Request, Service Request or Gap. It can have a list of status like, in development, in testing or done. You will be able to configure the list and if there should be auto numbers or you have the values in a separate helpdesk system. You can create tickets without an incident if it, for instance, is a business requirement
  • The ticket can get PI object assigned. So you can add any PI Repository or Repository object to the ticket, for instance, a message mapping or channel that has been changed for solving the ticket. When you look at a message mapping you can see which ticket it has been assigned to and thereby get information about why something was changed.
  • Testing from the ticket. It is then possible to calculate which Interfaces/ICOs to do testing on. If you are missing some tests you can add them. And then run all the tests.

You can get more information of the future of the tool by signing up for it at http://figaf.com/irt 

I have two videos about the concept. One that features the overall perspective and along with more explanation along the way.

The short direct to the point video

 

The long version with more explanation

You can get more information of the future of the tool by signing up to it at http://figaf.com/irt

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.

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.