How do you Document your SAP CPI Iflows

Documentation of integration has always been a strange thing. It has been pretty difficult to make sure we documented the details correctly and had enough information with. Normally you will just get some document designed to document some other thing and then try to adapt it to your integration. That will never give a good result. You may be compliant but just a waste of time if the documentation is not useful.

For SAP PI/PO we have for ages been using a Word template for the documentation of each interface. We support that with the Figaf IRT tool, so you can generate it fast. You can see an example of the SAP PI documentation here. The inspiration was to avoid having the documentation that was never updated and always had the initial version.

SAP Best practive

I did find an example of a SAP CPI template in the best practice guide. I did not like if for a few assumptions:

  • It was focusing on the wrong things that were a bit to detailed and too generic. Like a file conversion, or mapping it just has empty tabs that users need to fill in.
  • It could not be automated every well, which ment it did require a lot of user governance to host the information
  • It was juggling 3 different adapters and not showing the required details

I wanted to improve the process and make it even easier to capture the most important part of a CPI Iflow. It ended up with the following information:

  • Overview of the iFlow header information like name and description
  • History of changes logged with business requirements
  • Connection sender and receiver together with information
  • Test cases you have created for the tool
  • Flow description which is a table representation of the iflow. It will give some overview of how the different steps are connected
  • Configuration parameters configured in the full landscape, so you got some information on what is being used and the relavant resources.
  • Resources and the lat change data for them.

You can download an example of the document here for the SF to AD iflow.

There are ways to improve the document with more information. If you have anything that you think will provide value and make it easier to understand the documentation. Do let us know.

Automated documentation does have some limits like being able to update it different places, and add the extra information that makes sense.

You can try it own on your own iflows and see how it performs in your landscape.

SAP PI/PO B2B Add-on alternative

We will in the next period of time see a large number of users that will be performing migrations of their SAP PI/PO platfrom to 7.5. I have created a number of resources on SAP PI/PO Migration. One of the big thing in this migration is the migration from Seeburger to B2B Add-on. We do have a tool that allow you to automate the migration from Seeburger to B2B Add-on message mappings.

B2B Add-on from SAP does work and can give you a way to manage your EDI messages. There are still some gaps in the B2B Add-on solution that could be greatly improved and where i see that an alterntaive solution could be better. It is in the area of:

  • Logging and archiving of messages sent.
  • Partner management and settings usability
  • Configuration of partner connections via AS2, VANS or SFTP.

I had a webinar with Paw Pedersen from BizBrains that created a product called Link. Link is a tool build to manage your EDI solution. It is currently being used to manage B2B for Biztalk, but the same system can be used also for SAP PI/PO. They have been running it for a number of customers from small companies wanting to run EDI to big banks. You will learn about what the solution can help with. You can see the replay here.

They have a number of different configuration options and security settings that are required for banks. They also have large customers with many partners, so they know how to make the application scale.

One of the reasons I think it could be useful for you is that you can switch to their platform and then there is no need to upgrade to the PO license and can stay on the PI License. It can save you a great deal of money and speed up your migration process.

There is a number of different ways the Link solution can tie into your SAP PI/PO solution from

  • Just as an Archive of messages
  • Partner configuration
  • Partner configuration that updates your mappings
  • Using it also for SAP CPI.

If you find the product interesting write to psp@bizbrains.com, and get a trial of what the solution can do.

I will be a part of designing a good solution that will make your migration as simple as possible.

Figaf now improves your SAP PI/PO CTS transports

SAP PI/PO Change management and documentation have not developed much. And the full cycle of development is the same. It is really a manual process that requires people are spending a lot of time on documentation.

Is your Integration Important. Do you want to minimize the downtime and failures? Then the documentation and QA important.

If you are doing spending too much time on documentation, and if you are not you don’t have enough documentation of the changes made.

We have automated the full process from start to end designed to optimize SAP PI/PO. So you can get the transport documented with all integration objects have been changed.

This means that all your SAP PI/PO transports will be

  • Documented all your development objects
  • Changed link to a business reason, so you know how have approved the change and why.
  • Tested and validated in the QA system with same set of test cases, so you know that everything works as expected.
  • Configured in once place so developers do not need access to configure production system
  • Linking with the incident system so you can get information about what is wrong with your system faster

Check out the video

Because of the above reason, you will be able to:

  • Deliver integrations faster because of an automated delivery process with less time consumption
  • Happier employees because they do not need to perform documentation manually
  • Your QA process will be a lot faster because you don’t have everything delivered automatically
  • Higher quality with fewer errors because you are able to test all integrations fast
  • Fewer differences in the productive system because people are not doing modifications in other systems

Try IRT

We also support the same change management process for SAP CPI

Links to your SAP Cloud Landscape

As a developer one of the things that I often struggle with is to understand what system I need to login to to develop. With PI your learn to remember that PIT is the test system. But with CPI you just have some seemingly random numbers and it can be difficult to remember. I have received my fair share of emails with links in that I often go search for. I need to create a long series of bookmarks. And all new developers need to do that. Now we have made it easier for you to access the different pages.

I also normally added new tab names for each system so I can remember which system I’m currently have open in my tab.

With the new release of Figaf IRT 2.8 we are adding a function to allow you to configure your full landscape so you from the Figaf home page can go to all the relevant systems. Since we support transport and monitoring in your landscape you will anyway need to configure all your systems in Figaf IRT. You can also register all instances to a landscape so you will get links to all the entries in your environment.

The new homepace of Figaf IRT now look like this.

New Figaf IRT homepage with links to all your SAP Integration tenants or systems.

From each landscape you can then go to the relavant tennant and links. You can have multiply landscapes of each.

  • For API management it is both the developer portal and the API portal.
  • For PI it is /dir, Netweaver Administrator, PI monitor and B2B Add-on homepage
  • For CPI it is design, monitoring and IRT monitoring page.

If you have ideas to more then let me know.

We may add links to SAP sites like status pages or Cloud Platfrom links.

This feature will be rolled out to Figaf IRT Cloud and Figaf IRT around 14 May. You can get free access on either link. We also have some other cool features making your development process a lot easier.

SAP PI/PO Migration

There many companies working on migration or planning a migration of their SAP XI/PI to SAP PI/PO 7.5 systems. Over the years I have created a number of resources that make a lot of sense if you are in the process of considering a migration. Here is one place that you can find all my favorite resources on the topic.

Timeline

One of the drivers for migration is that the support of everything but 7.5 will end in December 2020. That is currently in 20 months time. Not a long time if you need to plan a project, get funding and running the upgrade. I would assume that the minimum time for a migration is 6 months once you got people working on the project. If you need to get the funding you know your companies budget process, so you better get started.

As I read the note 1648480 extended support will not be possible for the Java stack.

Options for upgrading

There are a number of options that you can use when upgrading your landscape. Product manager of PI/PO Alexander Bundschuh has written a list of the different options (13) that you have depending on where you are at the moment. What options for Upgrading SAP PI/PO

My recommendation is to go for a single stack system because the dual stack is not developed anymore. It will also improve your next upgrade because of a simpler architecture. You will have to covert your ABAP Mappings.

Your different options

There is also the option to migrate to SAP CPI, which is the cloud based tool for Process Integration. It have some areas where it can replace a PI and BPM solution, but there are patterns that are not fully optimal yet. It will no doubt be the place where SAP is focusing their development, so you will se a number of improvments there.

If you are not planning to use PO functions like B2B Add-on, BPM/BRM then it is probably best to keep at current license but move to an AEX, Java only version of your system. The only reason they would be to run CPI content on your PO system. If you have a few ccBPM probably consider moving them to CPI or Cloud Workflow.

If you are using B2B Add-on or want to run CPI content locally the PO is the way to go.

There is the concept Stack split that I have heard some customers use. The idea is to upgrade your 7.31 dual stack system to 7.5 with dual stack. In 7.5 they cannot share a system ID so one of the systems will get a new System ID. You will then be able to delete the ABAP system. So you only have a single stack system. It does require that you are using ICO’s for all your integration. I’m not sure if this is a supported process and how it works. Maybe your consultants know how it works.

Outlook

SAP PI/PO 7.5 will be in maitance until 2024. SAP have annonced there will be a new version of SAP PI/PO in 2022. The goal of this version is to support a newer Java version and latest Databases. Release will depend on when they become avabile from vendors.

There is a roadmap for the SAP PI/PO you need to search for Process Orchestration and then login to see the roadmap.

From what I can see on the roadmap it does not look like BPM and BRM function will be improved. You probably need to find another solution for BPM process. It could be the SAP Cloud Platform Workflow or CPI that will allow you to run it. The place where you will see most development is on running CPI content on SAP PO.

Process

The process for migration is pretty simple. It is just something about planning what to do. It does make a lot of sense to get an understanding of how you want to migrate so you can get started and know how it will work. I think it will give you some information to start the migration from. It can be improved and need to be adapted to your model. There are two areas that you need to focus on.

  • Planning: In this, you try to understand what you should be doing with regards to migration. This is where you need to figure out how to upgrade certain elements. This should be considered before you scale up the team. In this phase, you will also be able to see how you automate the solution.
  • Execution: In this part is about making the migration as fast as possible and keep the risk low. Here is where you make a migration of a single interface, test it and then move it to production.

You can read the full post and see all slides and the replay at the link bellow.

Automization of the process

We have been making a lot of tools for the SAP Platform and they do make a lot of sense to apply in any migration project. The more you can automate the easier the process will be. Here are some of the things you can consider for your project.

Understanding your current integration

To understand what part of your current integration and message mappings, we have created a free tool that allows you to see what is going on. It can give you information about which message mappings you have used and how many times they have been executed in the last month. It can also give you information about which modules you have and how they are used. It is a free part of the Figaf IRT application so it is just to try it out, so you can plan your migration.

Seeburger Migration

If you have Seeburger and are considering what options you have for migration then we have a path for it. We have created an automated tool that can take your Seeburger Message mapping and convert it to a B2B Add-on mapping with a few click. You can then save many hours in the migration process. You just select which mapping you want to convert and which B2B structure you want to use. Then the application will take care of the rest. It will cost you a fixed fee per mapping.

You can read more on the application at Seeburger Migration tool or at how the seeburger migration works.

Testing your migration

If you are doing any upgrade or change of your landscape it is really useful to perform test to validate that it works correct. I have in some cases seen that after an upgrade somehting on the mappings had changed behavior. It is therefore a good idea to be able to test that nothing is affected.

You have the following options to Test SAP PI.

  • Manual testing requires a lot of resources
  • SAP PIT a free tool from SAP to test from 7.5 sp14.
  • Figaf IRT a tool build to make it a lot easier to test SAP PI/PO. Is our tool designed to make upgrade testing faster
  • INT4 Iftt a ABAP tool made for testing interfaces. It is good for testing result in the ABAP tables

Comparison the two testing tools, I would recommend the Figaf tool because it makes the testing a lot faster to create and allow you to test your first upgrade. It also contains more patterns for testing and is able to test modules which is important with B2B Add-on.

Automation of the migration process

SAP have a tool that allows you to migrate channels and ICOs. It is a part of the PI system and you just link the two systems together and can then migrate scenarios or channels.

If you find that it lacks some part for processing and want a faster way to do the migration. We have a good understanding of the SAP PI Directory and Repository data model, so we will be able to create an automation for your. Reach our to info@figaf.com, to book a meeting on how we can help.

Anything missing

Is there something missing let me know.

If you any questions on your migration, sent a email to info@figaf.com.