IRT Transporting – Improve your SAP CPI life

In this blog, I will cower how IRT Cloud will improve the way you work with transporting.

Before we get started, we need to find a clear definition of what “DevOps” are. According to wikipedia it goes like this:

DevOps is a set of software development practices that aim to shorten the systems development life cycle while delivering features, fixes and updates frequently in close alignment with business objectives

Understand what is changed

Track what object is being changed
– Is it a part of the BPMN model
– Is it scripts or mappings
– Is it configuration which is changed

Register changes with business reason

Make a service request in the IRT tool, that allow you to link the changes to the reason.

User can assign changes in iFlows to it:

Test the changes

With the build in testing tool you are able to test the modification you make does not not affect anything unexpected.

You can document what test you have run and the result of them.

iFlow configuration in the landscape

Configure an iflow once and then let IRT handle configuration in the landscape once importing the change:

Transport individual

Be able to import changes into target system. Figaf will import the object into the target system. Then configuration will be applied:

Check out the demo

So, I if want to check out how this work, please take a look at the demo video below:

So, I you ready to try Figaf IRT/Cloud to see, what IRT/Cloud can do for you? I offer a 30 days free trial at https://figaf.com/IRTCloud.

Transporting SAP CPI content with Figaf IRT

We want to make it a lot easier to do SAP CPI transports and document changes, and it is also one of the things that i see people struggling with. I mostly also wanted to make it possible to transport individual iFlows, because it makes the process a lot faster; otherwise, you must create some packages to contain it.

A few weeks back i posted an image of me deploying a CPI change after just 40 minutes in production. One of the comments that, yes that is fine you can make changes in production fast if you do not do any change management. We did not have any change management or documentation. I would argue that with the changes you see below we can make it in the same time.

Another pain with transport was that you needed to reconfigure afterward. In Figaf IRT you have a central repository that allows you to configure what values you want across the landscape.

IRT will enable you to see what was before on in IRT. The easy way to do SAP CPI transport with Figaf IRT.


It on the Figaf.com/IRTCloud now and will be in the next release of our onpremish tool figaf.com/IRT soon. We still have some areas that we want to improve with the process, but it is better to get feedback on what you think of the solution. With the approach, we are not able to keep the old versions on the target system.

Make better regression test cases with Figaf Seeburger Migration tool

The Figaf Seeburger Migration Tool (SMT) allows you to migrate your existing Seeburger BIC solution to a native B2B Add-on solution. It helps to update your message mappings to use the new schemas created with the B2B Add-on. It makes your migration process a lot faster and has reduced risk. Some of the benefits of using the tool look as follow:

  • The new solution from SAP has a lot of advantages making it a lot more flexible and supports the newest schemas. It includes all EDIFACT, X12, Tradacom and EANCOM messages that you want to be using, so you don’t need to pay for each message.
  • It is also simpler to transport since they don’t require the use of the BIC to make the one to one mappings
  • It contains all the same adapters with some new features
  • The price of the solution is also included in your standard SAP PI price so you don’t need extra licenses to make sure you can communicate with EDI for your partners. So you can save money on the maintenance of the Seeburger solution.
  • You have the option to use the Trading Partner Management solution making it a lot easier to maintain many partners and the information from them

When facing the migration there are some challenges that you must figure out how to solve.

  • Schemas are different so everything needs to be remapped
  • Test nothing happens with the output messages.
  • Budget and planing

Do you want to try a package with 10 free mapping? Then check out https://figaf.com/tools/seeburger-migration-tool/

Blogs about Seeburger Migration

Do you want more information about SMT? Then please check out the blog posts below:

SAP PI Migration webinar

Migrating Seeburger to SAP B2B Add-on the fast way

Migrate from Seeburger to SAP PI B2B Addon webinar

SAP XI/PI dual stack to SAP PO/PI single stack migration

 

Full demo of Figaf on SAP PI/PO

In this video, I’ll show how the Figaf IRT tool will make it a lot easier to support your SAP PI/PO development. It supports the following process:

  • Look in support incidents for SAP PI
  • Create a ticket that could be similar to an SCR but created and updated in IRT
  • Based on the object in the Ticket IRT find which interfaces need to be tested
  • Run regression tests on the test cases
  • If you want to record new test cases IRT can also make that easy
  • It shows how you can anonymize the data to comply with GDPR or other data privacy
  • Validate the transport on QA/Test system to see if all transported objects work there.

We will make a similar video with a full demo of Figaf on CPI after the next release. 

 

Many integrated functionalities

Our ambition in the ongoing development of Figaf IRT is to create a tool with many integrated functionalities, so developers don´t have to look at different places when they want to solve their problems.  IRT is taking care of all your problems, and our customers say, it is easy to use.

Try out IRT

Doing SAP CPI Transports with IRT

Once I started to make my first SAP CPI transports I did not like that you needed to transport the full package. I wanted just to transport a single Iflow and log what was changed with it, then I knew what was being changed. But it was a rather difficult process to make sure you did correctly. So I thought we could optimize the process to make it easier to apply transports for single iflows.

So we have created a flow for developers where they will make the normal changes.

  1. Save it as a version in the development CPI system after normal development
  2. Syncronize the IRT with the CPI system (by clicking the button or wait for the scheduled synchronization job)
  3. Create a ticket and assign the object version to the ticket. A ticket can correspond to a Service Request or Incident. It is possible to update the version if you have multiple attempts to fix the problems
  4. From the ticket, you then create transport with one of the Iflow on the systems
  5. IRT can then import that QA/production system. It will delete the existing iflow and upload the new version.

I have recorded a demonstration video you can see how it works

The following are we working on before it will be released.

  • Fix some of the few bugs we have seen in our test environment
  • Have a way to get the configuration in a global table, so once you import an iflow on QA it will apply the configured configuration from IRT
  • Investigate if we can upload the new iflow without removing the old version.

There may also be other ways we can integrate this both with our testing application part and make a flow that better fits with a DevOps focus of development.

We expect this functionality to be released within the next few weeks both in our cloud application as well as the on-prem deployment of IRT.

Want to try it on your own system

Try out IRT

Try IRT Cloud