Why to go for PO against PI – Pros and cons using sample scenario

PO vs PI

If your client is using PI still and looking for option to migrate ,below RFP  will help with choosing a correct path and as of why it is better to go for PO 7.4 than PI 7.4 .

Below is a sample RFP that was used to propose the PO 7.4 migration to one of our clients . Hope it will be of some use to you.

SAMPLE SCENARIO:

XYZZZ customer, planning to upgrade their current PI box and looking for direction on the approach, timelines, and effort required to upgrade the current SAP PI 7.11 system.

Important & current PI implementation

• Current version of PI system is PI: 7.11,SP-Level : 04

1. Presently there are 30 live interfaces.
2. ccBPM, Java Proxy, custom adapters, 3^rd party adapters are NOT used.
3. No ABAP or XSLT Mapping is used in the landscape.
4. A three tier landscape is used; i.e.  Dev[]àQAS[]àProd[]
5. Additionally, a training system upgrade is also in scope; though without testing scope.
6. There are around n custom Z tables maintained in PI ABAP stack which caters for lookup & error and discard handling.
7. Around n out of nnn interfaces uses ABAP stack look up. Look up calls are done locally on PI ABAP stack (separate client) using RFC
8. Custom ABAP programs are present on the PI ABAP stack.

Available options

1. SPS Upgrade on current PI 7.11
   1. Upgrade SPS from 04 to 13.
2. Version Upgrade AND/OR Migrate to PI 7.4
   1. Upgrade OR Migrate to PI 7.4 dual stack system
   2. Migration to PI 7.4 AEX (single stack)
   3. Migrate to PI 7.4 Process Orchestration (single stack/ AEX+BRM+BPM)

A.OPTION 1 – 7.11 SPS Upgrade 04 à 13

Pros:

Minimum efforts

Minimum cost

Minimum down time

No additional hardware requirement envisaged

Minimum impact/involvement of functional teams.

Cons:

Missing the latest capability of PI (includes performance, TCO, enhancements in standards based inter operability, design governance etc.)

Non alignment to future roadmap of SAP PI

No component based alerting; classical alert framework. (CBMA supported from 7.31 onwards)

B.OPTION 2 – 7.4 Dual Stack Upgrade OR Migrate

  Pros: 

-Largely backward compatible with 7.11 dual stack. Probably, most of the scenarios will be unaffected by the upgrade.

-Less effort as compared to migrating on single stack (AEX/PO) but more than SPS upgrade.

-Existing look up strategy can be continued.

-Instead of AEX, AAE can be used.

-Basis team must be involved to understand from hardware perspective.

Cons: 

 –More testing as compared to SPS upgrades; however less than moving to single stack AEX/PO.

-In ability to use AEX.

-No tight coupling with BPM, BRM as compared to PO.

-Future roadmap of SAP is for single stack and not really a dual stack

C.OPTION 3 –  7.4 PO Migrate

Pros:

-Major performance improvement with usage of AEX (Advanced adapter engine extended)

-High throw put

-Less TCO; hardware cost almost halved.

-Single system monitoring; compared to double earlier.

-In line with SAPs future road map.

-HANA compatible

-Large messages (size) and high volumes can easily be supported

-Component based alerting (CBMA)

-High benefit of tightly coupled BPM and BRM; as they are installed on the same server

Cons:

-Migration will be needed and will involve more efforts as compared to sps upgrade.

-New hardware will be needed.

-ABAP stack look up tables will need to be moved onto java stack.

-Regression testing must be involved.

-All IDoc related interfaces will need to be reworked to move them to Java IDoc adapters.

D.OPTION 4 – 7.4 AEX Migrate

Pros:

-Major performance improvement with usage of AEX (Advanced adapter engine extended)

-High throw put

-Less TCO; hardware cost almost halved.

-Single system monitoring; compared to double earlier.

-In line with SAPs future road map.

-HANA compatible

-Large messages (size) and high volumes can easily be supported

-Component based alerting (CBMA)

Cons:

-Migration will be needed and will involve more efforts as compared to sps upgrade.

-New hardware will be needed.

-ABAP stack look up tables will need to be moved onto java stack.

-Regression testing must be involved.

-All IDoc related interfaces will need to be reworked to move them to Java IDoc adapters.

Other Value Adds to consider post migration

SAP has Introduced Secure Connectivity SFTP PGP and B2B Add-ons from March 2012. In near future (based upon project requirement) SAP security (SFTP / PGP) and B2B Add-ons can also be considered. Such as for any EDI implementations in future or EDI migrations SAP PI Add On can be considered.

Some of the features of these Add-ons are mentioned below :

1. B2B Add-ons support AS2 adapter, OFTP adapter, X400 adapter, B2B content, Mapping Functions, NRO archiving Modules and EDI converter modules.
2. There will be no dependency on EDI tools / third parties like Seeburger, Aedaptive etc. with the use of new SAP PGP  and SAP Add-ons.
3. Tight integration with SAP NetWeaver Process Integration/Orchestration
4. Same underlying NetWeaver/PI technology framework for monitoring, channel
5. Scheduling, message splitting, configurations, administration etc.
6. Encryption, Signing and Compression capabilities
7. Communication Protocols Support (SFTP, AS2, OFTP, X400)
8. Different EDI Formats support (EDIFACT, ANSI X.12, VDA, TRADACOMS,ODETTE, Custom Formats)
9. Ready to use ESR Content (XSDs, Mapping Templates, Mapping Functions)
10. Multi Message handling Support
11. Modules for special B2B use cases (Archiving, Automatic Counters etc.)
12. EDI XML Converter for maintaining B2B Content and extensions.
13. Functional and Technical Acknowledgements

No License is required for SFTP PGP and there is a separate license requirement for B2B Add on