banner



How To Create Iflow In Sap Pi

Hi All,

Now here i want to share my experience about Migration Process SAP Dual Stack 7.31 to SAP Single Stack 7.5 on HEC and now my Migration Project Progress was on going and hopefully will be working well for all ........ ✌πŸ˜„

As we know earlier that SAP will stop support for SAP PI Dual/Single Stack 7.1 until 7.4 at 31 Dec 2020. The only option to still getting support for your SAP Middleware system is upgrading or Migrating your SAP Middleware system from PI Dual stack/Single stack version 7.1 until 7.4 to PO Single Stack 7.5 Version.

Now we're talking about how to migrate your PI System to PO system specially from Dual Stack to Single Stack. First of all we need to know what is PO and what's the different between PO single stack and PI dual stack.

What is PO ?

SAP Process Orchestration or we usually call it PO is Java Stack Only Middleware Product package from SAP includes AEX (Advanced Adapter Engine Extended), SAP BPM (Business Process Management) and SAP BRM (Business Rules Management) and introduced by SAP at 2012.

Now What's the Difference between PI Dual Stack and PO Single Stack ?

The Biggest difference and Change for me from SAP PI Dual Stack to SAP PO Single Stack is we were losing SAP PI ABAP Stack that we usually use it for Monitor Message (SXMB_MONI), Server Configuration like adjusting Java System Parameter, Transport Request Number management (TR) and also Queue Management.

The other difference was on ESR (Enterprise Service Repository) and IB (Integration Builder). So far if i check in ESR, ccBPM were no longer available since we already have SAP BPM in PO. In IB there several change from PI Dual Stack, now we were using ICO (Integrated Configuration Object) because Classical object like Receiver Determination, Interface Determination, Sender Agreement and Receiver Agreement no longer available. Basically ICO are already in PI Dual Stack before but i usually using Receiver Determination approach before when using PI Dual Stack. There also IFLOW or Integration Flow, Again its also not quite new. IFLOW already available since SAP PI 7.31 ✌. IFLOW was an optional object, your interface will still running well with just ICO without IFLOW. But for me IFLOW was Required object since it will help me a lot for maintenance purpose, it also easier to create IFLOW then generate ICO from IFLOW rather than create an ICO. With IFLOW you also can see end-to-end scenario looks like clearly.

Note that you need an Eclipse NWDS to create an IFLOW because you can't create it in Swing Client (IB and ESR)

Now we get into the main discussion about Migration SAP PI Dual Stack to SAP PO Single Stack.

First we will talk about Migration Strategies.

What ? Strategies?

Yeps.... Just like a war, We need Migration Strategies and Plan to make everything running well, smooth and the important things was should be finish on-time.

Migration Strategies we will talking about how long the Migration Process will take, Server Calculation, Impact Analysis, Object Analysis, Potential Issues, Preventive solution for Potential Issues and of course we need choose Migration Approach which one suitable to our environment.

Please take note that all the Migration Process and Strategies will depend on your PI Landscape, Object Condition and Complexity 😁

Now we get into Migration Approach, There 2 Migration Approach we can use:

  1. In Place Upgrade

What is In Place Upgrade ?

In Place Upgrade its means that you perform upgrade activities your current PI Dual Stack to PO Single stack and do all conversion object activities including ABAP Object, Java Object (Mapping) and ccBPM directly there.

Conversion Object activities can be done manually or using Migration Tools provided by SAP.

Note : We will talking about Migration Tools Later πŸ˜„

2. Side by Side Migration

Side by side its means you need to install new PO Single Stack that will running next to your PI Dual Stack that will act as source system. Most of your Migration Process including Conversion object will be in new PO Single Stack , the activities will be :

  • Setup new PO Single Stack server configuration and Migrate SLD Object from PI Dual Stack
  • Export all Interface Object in Swing Client into TPZ file from PI Dual Stack then Import it in PO Single Stack in case you are using ICO instead of Receiver Determination, if you are still using Receiver Determination, ccBPM or another ABAP based Object, you need to re-design your object manually or the other option you can use Migration Tools Provide by SAP

In my case i use Side by side Migration approach and Migrating all Interface Object both manually and using Migration Tools for some case.

Migration Tools

Migration Tools is a tools provide by SAP and available since SAP PO 7.31. The Purpose of this Tools is to make your Migration Process easier Specially for handling Classical object scenario ( Receiver Determination and it Friends πŸ˜‚) and converting to ICO or even IFLOW.

Cool ... is it Really ?

Hang on.........

For some case yes but for another case this tools successful to make do double workπŸ˜‚

Hopefully SAP team can fix some bugs in this tools ASAP πŸ˜„

Lets back to the topic

You can access This tools using directly following URL http/s://<your target hostname>:<port>/webdynpro/resources/sap.com/tc~pi~tools~dirmig~wd/DirectoryCockpit#

Migration Tools Homepage

You also need following user Roles in both Source and Target System to use this Tools:

  1. SAP_XI_API_DISPLAY_J2EE

These roles allow the execution of the following Integration Directory API operations:

  • Query
  • Read
  • Check
  • GetState, CheckContent, GetCacheState, GetObjectIdentifier (only for access to change lists)

2. SAP_XI_API_DEVELOP_J2EE

These roles allow the execution of the following Integration Directory API operations:

  • Change
  • Create
  • OpenForEdit
  • Revert
  • Delete
  • CreateFromTemplate (only CommunicationChannelService)
  • Activate
  • Revert (only ChangeListService)

This Tools have 3 main function:

  1. Scenario Migration
  2. Channel Migration
  3. Configuration

Lets Describe it

Scenario Migration

Yes..... This function is to convert your Classical Scenario into ICO or IFLOW. Its not only convert you scenario but also bring all your channel inside scenario include channel information like server, username, directory, filename or anythings except password into your new PO.

You can also rename your Channel, Business Component, IFLOW and Configuration Scenario.

Insane.....

But you need to pay attention and take care while you do mass production using this tools. Its working fine when you do it one by one scenario. But when i try to do mass migration even i have rename all the object the result in target system is only first scenario got rename, rest of scenario still using old or default name. Like what i said before i do double work with this tools 😴

Channel Migration

This Function is to do mass migration your communication channel from source system to target system and also bring all channel information except password. Just like Scenario Migration you also can rename channel here.

Configuration

Honestly i never touch this function before. But when i check it, its look like we can add another Source system here in System Tab and another Tab was Renaming Rules its looks like function that you can create mass renaming object by using rules (not sure still need to check it).

Another Topic i want to share here was.........

Potential Issues While Migrate

Who is here like issues ?

Just like proverb

There are two sides to every coin

Issues can makes you stressed, frustrate and working extra hours to solved it but in the other sides Issues will teach you a lot of things and be a master, without issues you almost learn nothing 😎

Lets back to topic

For Potential issues, again it will be depend on your PI Landscape, Object Condition and Complexity. For this session i will explain based on my experience issues that i face it before in my Migration Project . I make it into 2 category for issues here, Predictable and Unpredictable Issues.

Predictable Issues

  1. Since Our migration also to HEC, we were facing issues that HEC not allow FTP connection to external network. Which means we need to change all external FTP connection into SFTP and do some re-work in channel including testing with external parties.
  2. Java Mapping Compatibility, Our PI Single and Dual Stack running on Java JDK version 1.6 and new PO system will be running on JDK version 1.8. That's why we need to check and recompile all of Java mapping into similar java version with PO system. or another way is PO Import Archive in 7.5 have a function call JDK Compliance, with this function we can choose which java version compiler we use. but still need to check and test is it working for us or not. As a preventive solution,we recompile Java Function using similar PO java version
  3. Converting Classical Scenario object into IFLOW/ICO , even we have Migration tools, we have to do manual converting for some interface because it need special treatment.

Fortunately we don't have any ccBPM object so we don't need to do conversion from ccBPM to BPM. Also if you were using Proxy connection from SAP ECC or SAP S/4 Hana to SAP PI/PO, you have to change Sender and Receiver Channel from XI adapter (if still using it)to SOAP Adapter with message protocol XI 3.0, Another work to do if you were using XI is you need to regenerate class in sproxy and make sure class name was similar with previous or you need to do some adjustment in ABAP Program (for this case im not sure if it need or no since im not using Proxy connection).

Unpredictable Issues

  1. SAP Migration Tools, unfortunately it can't work for us for all interface, we need to do some manual work because this tools was not working well for some case.
  2. SLD Sync Problem, sometime when we do manual work by creating IFLOW from scratch, we can't assign properly in IFLOW even we already export import ESR object into new PO. Its looks like we need to do some additional work before we can assign proper object in IFLOW.
  3. Useless Configuration Scenario, While we transport that include Configuration Scenario from Source system into PO Target system, our old Configuration Scenario looks useless because we need to create new Configuration Scenario from NWDS while creating IFLOW Manually and delete the old one. Its means that we don't need to include Configuration Scenario while exporting from Source System (It only applicable if you create IFLOW in target system from scratch)

There's several potential issues that i faced before and of course there's another issues upcoming and maybe another surprise issues that i can't describe it here since it was a Kitchen Secret Recipe πŸ˜„ πŸ˜…

There also a tools that can help you for testing after you do object migration it should be easier if we can automate your interface testing process.

Note : Thank You Michal Krawczyk and teams for this tools πŸ˜„

Hope you can enjoy reading and get some point of view about SAP PI Dual Stack to SAP PO Single Stack Migration. Forgive me if there any wrong information or mistaken here.

Happy Migration.......

Cheers ...🍻

Thank You,

Regards,

Iman

How To Create Iflow In Sap Pi

Source: https://www.linkedin.com/pulse/migration-from-sap-pi-dual-stack-po-single-khoirul-iman

Posted by: parkblegame94.blogspot.com

0 Response to "How To Create Iflow In Sap Pi"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel