Casestory: Using Figaf IRT before testing SAP PI/PO upgrade

/0 Comments/in , , , , /by

Almost a year ago I had the great pleasure of having Mark Oshifeso on the sixth episode of the Integration Podcast. Mark was one of the first users of the  Integration Regression Tool for SAP PI/PO. Mark works for a mid-size oil and gas producer based in Texas, and he and his team found out, that using Figaf IRT made it a lot easier to do upgrades of the SAP PI/PO system. I haven´t had the resources to go deeper into the interview before now, but I do think it is interesting because Mark Oshifeso has some great insights from a customer point of view.

The episode was called How to automate SAP PI/PO testing with Mark Oshifeso from Anadarko Petroleum.

Stock image

You don´t need to be a scientist

By using Figafs IRT-tool Mark Oshifeso was able to test much faster.

“The tool is crazy easy to use. It is another generation from the usually SAP-tools, you list your Iflows, you mark those ones, you press record, and it is basically listening to messages in for example production. Once you have done that, you can run your test cases” Mark says and continue:

“The IRT tool helped us run a test circle with almost no human interaction, and we are now in the situation that we upgraded our production based on the automated testing, and we are hoping now to move from a 2-3 years cycle to a 6-month circle.”

Our ambition at Figaf is to create and keep on developing on the tool, so it is easy to use even in companies with many interfaces. Mark Oshifeso agrees that the tool gives a great overview in the process of the testing:

“It is easy to use, you don´t need to be a scientist, and this is really why we were able to introduce the tooling into our landscape of 300 interfaces. Some companies have more than 20.000 interfaces,
and if you have a large number of interfaces you need to have an easy tool. The tool helped us automate the test. The tool is really intuitive.”

“With IRT tool there is a very fast learning curve, and if another person takes over, you have people quickly getting familiar with this tool. There is no science, which is also why we choose it.”

There is no waiting anymore

What we want at Figaf is to give people a chance to optimize their workflow by using automated testing. And fortunately Mark Oshifeso thinks, that we have achieved this:

“The tool it selves is very speedy to use. There is no waiting anymore. The tool is really great to help facilitate, save money and especially save so many hours. The figaf tool is the most holistic approach, and easy to get everything set up, I don´t see anyone else so far on the market”, he says and finishes:

“I can really recommend this tool, if you want to go to automated testing, this is one of the tools
I would really look into.”

Here you can find the podcast: How to automate SAP PI/PO testing with Mark Oshifeso from Anadarko Petroleum.

As you can see Mark Oshifeso had great success using the tool. Since the interview we have made many improvements to the Integration Regression Tool, so I should be even more easy to use today.

Download IRT for now

 

 

SAP PI Migration webinar

/0 Comments/in , , , /by

So, on January 15. 2018 I held a webinar I webinar about SAP PI Migration. In the webinar, I talked about my 7 step plan for migration of SAP PI to a single stack. The 7 steps look as following:

  • Goals
  • Current integrations
  • Pattern mappings
  • Resource consumption
  • Migration phases
  • Development
  • Testing

The plan covers an initial assessment on your landscape and an idea of where you want to move your landscape.

Here you can watch the replay on the webinar:

If you want to know more you can also take a look at the blog post 7 steps PI PO migration, which was published on September 25., 2017.

You can also take a look at the slideshow: SAP PI/PO migrations – How to save time and lower risk on your projects:


Lastly, when you are interested in migration, you might want to take a look at this:

  • 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 update your message mappings to use the new schemas created with the B2B Add-on. It makes your migration process a lot
    faster and have a reduced risk

How to start from scratch for using SAP PI/PO

/0 Comments/in , , , , , /by

If you just purchased SAP PI/PO there is a lot of things to consider. This post will help you in the process of figuring out what is interesting.

The thing is you don’t know too much but it will have the greatest impact on what is set up. So it would be a good idea to have an architecture workshop where you will get all the insight into how you can create a solution that matches what you want to achieve. So it is an ideal time to get help.

I have created a mindmap video where I cover some of the most important things about the process. Watch the video below.

Architeture

A big thing is to get the architecture to match what you want in your organization. There a lot of things to consider like naming conventions and how to create interfaces. This should you would hopefully get a few sample interfaces that show how the things would look and how to monitor them. You should also consider how to make documents required for it both mapping documents if required and documentation.

It may be a good idea to have a secondary consultant to help you in the process that is on your side because you don’t know as much about what you can expect.

 

Testing

Testing is one of the important things in the process. If you “just” replace middle where you have the ability to get input and output document. If you use the Figaf IRT for SAP PI/PO testing then you will be able to perform the tests to verify that messages look identical. This way you can save some time for testing the application together with business experts.

If are doing a greenfield implementation of SAP S/4 ERP then you will have to change the interfaces on both sides. You will still have to setup testing so you can ensure that the process works correctly even when you have to apply support packs.

Migration

A good place to start is also my migration guide. It is much the same things, except that you have more free hands with what you want to do and the changes that you must make.

There are some of the things here that can be applied to the list of attributes to collect from each interface. You can find it in the slides. If you can get the information it may be a lot easier for a partner to do a good estimation of the project. You may add data like a number of fields in each interface to give better information about required mapping size maybe group it in to bucket like 1-20 , 20-100, 100+ fields that need to be mapped.

7 steps to a SAP PI to PO migration

Cloud world

In this blog, we have not been covering any of the SAP platforms that may be interesting and save some time on integration. There is the SAP Cloud Platform Integration (CPI aka HCI) which is a solution that is quite simply to PI but cloud-based and more flexible. It contains a lot of prebuild content that will speed up and integration, so it may be used in some scenarios. You may also be able to run this type of interfaces on your new SAP PO system. For some integrations, it may be beneficial to use because of the flexibility and the availability of adapters.

Other advice:

I ask the question what people would like to have known before they started on the SAP PI/PO project a long time ago and I did get some interesting answers that may be quite in line with what you are looking for. There was a lot of ideas about making better guides for what should be implemented. You can read all suggestion here.

 

Good luck on your new platform. I promise it will be an adventure. 

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

/5 Comments/in , /by


Migration from a dual stack SAP PI to a single stack SAP PI/PO system is a big task.

Many organization is at the moment is in the process of migrating It is away to stay agile and be able to use the newest releases and solve the issues the business requires.

There is also some performance reasons to move to a new SAP PO system because it optimized for faster processing of messages and easier maintenance. PO will also allow your users to interact with processes across the platform.

There are two approaches to it.

1) Upgrade the dual stack system to 7.5.
2) Fresh installation of 7.5 single stack

1) Upgrade to 7.5

With 7.5 the ABAP stack is separated out to a new system id. This feature enables you to delete the ABAP stack and giving you a regular 7.5 system.

There is also the option to upgrade and keep the system as a dual stack system. I don’t think it is a good idea because you are stuck with the same infrastructure and have to get away from the dual stack at some point.

The benefits are:

  • That you don’t have to configure a lot of things again.

The challenges are:

  • It will be a big bang implementation, and everything is moved at once. You better hope it will work after you have tested
  • There is a requirement that you only have configured everything with ICO so it is a java only installation.
  • You don’t have any ccBPM or that you can easily convert the processes in the upgrade.
  • It is not a supported upgrade from SAP, but some partners can do with success.
  • Long downtime while the update takes place
  • You have to be migrating from a 7.31 or 7.4 system for this to be an option.
  • It is difficult to perform any support while the operation takes place.

2) Fresh installation of PO

It gives you a fresh start on your development so you can configure the interfaces with the newest approach.
There is migration tool on SAP PO, which will allow you to migrate dual stack flow to ICOs. The tool has some limitations and will not be able to migrate everything.

The benefits are:

  • You can migrate one interface at the time or in batches. So you will not have any downtime and can verify that the new system works.
  • You can check the new adapters work if you are moving from a Seeburger AS2 to SAPs AS2 adapter.
  • You can use the BPMN modeling tool from the beginning of the project.
  • New platform running on newer hardware and operating system.

The downsides are:

  • It takes a lot of time to move everything gradually.
  • There needs to be coordination with partners to make sure that the messages work correctly.
  • You will have two landscapes for a period that you will have to maintain.

Steps in the migration

A migration should consist of the following moving of objects.

1) Perform a proof of concept test to determine if the new system is working as expected. My experience has shown that there are non-critical messages with low volume that can be switched over to see if those work correctly, without risking the test on critical messages. If something is wrong with the process it is possible to do later.
2) Migrate the high-volume elements and continue to monitor how the migration is working. You want to be sure that your new system can handle the workload; although hopefully, it should be easier to get the same number of messages processed.
3) Move on to the critical interfaces. Now you have a proven system and you can move critical interfaces and make them run better on the new system.
4) Migrate the remaining interfaces. This is the part that can take a long time, especially if you have interfaces that run once a month or less.
5) If the business has requested any change to their existing interface, now is a good time to migrate those interfaces as well, since it will need to be done at some point anyhow. This also makes for a cleaner migration because you will have only one place where development needs to be done. If it involves three parties that will need to make changes, then it is best to migrate it all at the same time.

 

Testing

For both points, there are some challenges with the testing. You don’t want to test too much with the business. Business people often don’t care about such migration because it will not give them new ways to reach out to their customers.

There have been reported some changes in how adapters or message mappings work. They are not a big difference but if your application is using some of the features affect it can have a serious impact on your business.

You will need to ensure that messages processed will not be any different once they are processed on the new system. It can take some time but if you can perform it automatically, then you are far ahead.
There is the Integration Regression Tool from Figaf that allows you to easily test SAP PI/PO integrations. It does take some effort in getting up an run, but it will enable you to test better and with a lot more documents. It will also allow you to install patches more often and ensure your system is on the latest release.

There is the Integration Regression Tool from Figaf that allows you to easily test SAP PI/PO integrations. It does take some effort in getting up an run, but it will enable you to test better and with a lot more documents. It will also allow you to install patches more often and ensure your system is on the latest release.

Get the test tool

Seeburger to B2B add-on

I wanted to have a full section on seeburger. Because it is one of the technologies that are going away. If you are using it it does have an enormous impact on your business.

If you are using Seeburger EDI converter or tools there may be quite a bit of extra work you will need to migrate.
Last time I checked Seeburger does not support on 7.5, so you will have to migrate all your Seeburger tools to SAP B2B add-on in the process. Even if Seeburger supported 7.5 it would still make sense to migrate because B2B Add-on has more features and can simplify your landscape.

The adapters are configured differently, so you will have to learn how to use the B2B Add-on adapters instead of the Seeburger version. There are some differences, so it is not possible to do an automated conversion of them. For instance is AS2 Partner number on the B2B Add-on adapter where seeburger is using the attribute from the parties selected.

For EDI handling there is also some differences.
For the EDIFACT, X12 messages the XSD structures is a little different, because some elements have been renamed and changed position. Users will, therefore, have to remap the two structures. This change can be done in different ways:

  • Create a XSL(T)/Message mapping that can convert between the seeburger and b2b addon message. That way you can continue using your existing mappings. It will cost some runtime performance to do the conversion between the formats.
  • Remap the message mapping to follow the new format. Repository helps with this. It will experience say it takes around 1 hour pr message.
  • Remap using a tool like SMT from figaf. This does the smae as you would do in the repository but just automated. For more information see https://figaf.com/tools/seeburger-migration-tool/

The inbound processing of the EDI document is also different. You can use one connection for all inbound document because you can use the Trading Partner Management (TPM) to customize each partner.

The TPM many also enable you to restart all mapping all your messages so they follow the newest conversion. It is a big task but may simplify maintenance of your documents.

See also
https://blogs.sap.com/2016/04/06/b2b-addon-compared-with-seeburger/

Get more infomation

Happy migration

 

Retiring the SAP PIDocumenter and Diff tools

/0 Comments/in , , , , , , , , /by

I have retired my documentation tools.

The reason is that they used an old form for documentation and SAP PI/PO did no longer support the use of XIM files. It was therefore not as much the tool was used anymore.

I have created a short guide to how you can export your mappings to an Excel sheet with NWDS. I’m not to found of the layout of it but it does support standard and also export UDFs. So it is an easier way to make the documentation.

How to document SAP PI/PO Mappings using NWDS