PI Dual Usage or Process Orchestration

[elizabeth_stapleton]

Hi all

I am hoping someone can best advise where to look

We are currently in a dual stack 7.1 scenario, looking to upgrade. The options we are looking at are PI 7.5 dual usage and Process Orchestration 7.5. We have discounted PI single stack as there appears to be a few references to limited PI facilities with this.

We have varying points of view as to whether PO will restrict our PI functionality too, though I know it comes bundled with new stuff we don't currently use, BRM and BPM.

I am working my way through lots of documents on PO and any I can find on dual usage. My difficulty is finding something useful but objective, most of the info on PO is almost sales pitch.

Due to time restraints we are trying to identify the option most like what we currently have in terms of PI config. Which seems to be dual usage.

With PO being java only we have questions around being able to continue using ESR Imported objects like

Idoc structures FIDCC1.FIDCCP02

RFCs to ABAP code e.g for Z_Duplicate_file_Checks used in our mappings

plus ABAP proxies

and our preferred graphical mapping (no experience with java or stylesheet stuff)

Netweaver developer studio would probably also be somewhat of a learning curve.

What we don't want to have to do is re-write our current interfaces for a Java only set up.

We are mostly File adapters, some JDBC, one Web service. Standard Idoc inbounds, quite a few proxies in and out.

Future directions for us include using the Cloud. In preparation for that we have installed a single stack PI 7.5 purely for routing between us and the cloud via the DMZ. This has yet to be released to me for having a look round, so no idea what this comprises yet. We are also in the middle of a SAP mobile project, which is proceeding with difficulty. I suspect PO will assist with future mobile work, though dual usage probably will too.

I think predominantly we are concerned we don't end up with a solution that will take away functionality what we currently have, mean re-writing existing interfaces, learning new concepts, technology and terminology, and be a hurried affair that leaves everyone confused and slows down some future planned projects.

Any pointers would be gratefully received

Thanks Elizabeth

[vadimklimov · Accepted solution]

Hello Elizabeth,

Looking into overview list of technologies you mentioned as subjects for potential migration from PI (dual stack) to PO (Java only), I don't see any of them that would only exist in dual stack, and not implemented / ported to Java only - namely:

• Mappings. Particularly, graphical mappings. Under the hood, they are anyway compiled into Java programs, and in general, they are finely migrated from dual stack releases to Java only installation options. Having written so, I shall note that it is still recommended to run regression tests after migration, as there were some changes in in behaviour of standard mapping functions (good news are, most of them happened when migrating from release 7.0 - so given you are migrating from release 7.1, you shall not experience many differences, if any at all).
• Adapters. RFC, File and JDBC adapters were originally Java based adapters in dual stack, so they get nicely migrated to Java only. Classic (ABAP based) IDoc and XI adapters have their Java analogues - IDoc_AAE (for IDocs) and SOAP adapter with XI message protocol (for proxy). As for web services, it depends on what type of web services you use: if SOAP, then SOAP adapter was originally Java based, so is migrated finely, if WS-RM or HTTP (that are both ABAP based in earlier dual stack releases such as 7.1), then PO has Java based WS_AAE and HTTP_AAE adapters that can be be used instead. Moreover, you might check Integration Directory Migration Tool (that you can find built in and shipped with your PO 7.5 system) that automates migration activities of configuration scenarios from dual stack to Java only scenarios, including conversion of communication channels from ABAP based adapter types to their Java only analogues, where applicable.
• Development tools. Vast majority of interface development activities in PO systems can be done using classic ESR and Integration Directory tools. There are few exceptions though - such as, iFlows in Java only systems can only be created via NWDS, and not in Integration Directory - but it is minority of such features. NWDS is promoted as the preferred tooling when working with SAP PO systems, but ESR and Integration Directory are not deprecated and can be used side by side - thus, making your experience in transition from ESR / Integration Directory to NWDS more incremental and smooth. For example, you can develop ESR objects (such as data and message types, interfaces, mappings - and, by the way, yes, you can go ahead with usage of imported objects in PO 7.5 in the similar way as you did in earlier releases of PI) using classic ESR tool, communication channels - using classic Integration Directory tool, and start making use of NWDS for iFlows and alert rules development. Then you can gradually move remaining Integration Directory based development activities to NWDS, and complement them with transition of ESR based development activities to NWDS, too.

I'm not entirely sure if I understood your statement regarding usage of RFCs to ABAP code such as for Z_Duplicate_file_Checks in mappings correctly. Do you mean, you make use of ABAP mapping programs in PI, where you make RFC calls to external ABAP systems? If so, then ABAP mapping programs in PI will have to be re-developed and re-implemented using alternative mapping techniques (graphical, custom Java mapping program or XSLT - the latter is less common when dealing with RFC calls being issued from the mapping), when migrating to Java only, and there is no conversion tool that would automate this process - this is a manual activity. Although, I would suggest checking if you can review implementation of such mappings and re-develop them using graphical mapping functions, as RFC lookup function is a part of standard mapping functions library provided in PO 7.5 (well, to be more precise, it was introduced already in PI 7.1).

As for usage of PO 7.5 for cloud integration - that is significantly broader topic for discussion. PO 7.5 is well-equipped with functionality that can be utilized for on-premises / cloud integration scenarios. The other option from SAP integration products' portfolio, that is also suitable for mediated cloud integration, is SAP Cloud Platform Integration (CPI) offering, that can be used as a complementary platform to already running SAP PO landscape. Looking into product positioning, PO is positioned as appropriate tool for on-premises to on-premises and on-premises to cloud / cloud to on-premises integration scenarios, whereas CPI is positioned to be a better fit for cloud to cloud as well as reasonable alternative to some on-premises to cloud / cloud to on-premises integration scenarios (note overlap for hybrid - on-premises to cloud / cloud to on-premises - scenarios when positioning PO and CPI). Decision on which tool to use for integration of on-premises systems with cloud systems and services is not that straightforward and there is no single correct answer for this question, as it highly depends on if your company invests into SAP Cloud Platform in part of other services (and then CPI can become logical extension of that subscription) or not (and then CPI alone might not bring that much value and usage of PO for such hybrid scenarios can become sensible choice). If your strategy is to utilize more cloud services and applications in the future (hence, potentially increasing share of cloud to cloud integration scenarios and ultimately bringing them to overwhelming majority), then it might be worth looking into hybrid integration platform in a longer term.

Regards,

Vadim

[elizabeth_stapleton · Accepted solution]

Hello Vadim,

thank you for your very thorough response. It will be most useful for us, whilst picking our way through our upgrade project.

Regarding my comments about RFCs, ABAP and our Z_DUPLICATE_FILE_CHECK....I attach screen shots of what we use. ABAP code on ECC, where files called ZTINT_FILEOUT and ZTINT_FILEIN exist, and hold the file names loaded. The ABAP code checks these tables to see if the current file (name) being loaded, already exists. Am I right in assuming we need to write some java code to access the ECC tables instead and return whether the file exists or not? function-module-se37.pnggraphical-mapping.png

Kind regards

Elizabeth

[vadimklimov · Accepted solution]

Hi Elizabeth,

I'm glad if you find information in the reply helpful. Regarding function modules - I got your point now: earlier I was unsure if you have them in ABAP stack of PI system (this will require modules' re-implementation when migrating to PO) or in the called ABAP system (then migration to PO doesn't impact called modules). From screenshots you provided and your description, I can see now that this function module is located in SAP ECC, and you implemented RFC lookup function in PI's graphical mapping to query it. RFC lookups to function modules located in ABAP based backend systems are finely supported in PO systems in the same way, as you did in dual stack, so you should not have issues with querying it from within RFC lookup in your graphical mapping in PO.

Regards,

Vadim

[elizabeth_stapleton · Accepted solution]

Absolutely fabulous Vadim!

We were gearing up to some mass Googling on Java and some training courses. We will still do that, but not so urgently. Thank you so much for your help

Elizabeth