Imagine you firstly installed PI 7.3 with ICo and wondered how it’s pretty simple to configure integrations.

Moreover, you were using the same ideas and toolset as it was introduced to XI 2.0:

• 3D-addressing (party|system|iface)
• SPROXY and interface reusing in both PI & ABAP
• Enterprise Services Builder and mappings/context objects/etc from design-time
• Integration Builder with channels, scenarios

So, the shift from XI 2.0 to excellent PO 7.5 single-stack was smooth and usually you’d need to reuse you dowry.

Not only you (integration consultant) was trained to SI_MoneyGone_OutAsync but end-users and functional consultants too.

Nowadays if we look around future integration buses, we can see no any addressing and SI_Something_OutSync is here. You have to use raw endpoints and wsdls, to train your consultants to very new monitoring UI and so on. Of course the progress requires you to spend not only money but sacrifice outdated ideas as well.

I think the PI 7.3 is not outdated and we can translate old ideas to new modern Camel-based bus (any of them) and re-use both ESR/IB as well. In the target vision we will have Fake Adapter Engine which:

• Registers in SLD automatically
• Listens on /CPACache/invalidate and receives cache updates
• Translates Communication channels plus ICos into Camel-route
• Stores message monitoring in terms of addressing
• Provides monitoring to Central AE using /ProfileProcessor and /AdapterMessageMonitoring so PI consultants will be able to use the /pimon natively

For better configuration ability we will use especial CamelAdapter metadata, so endpoints will be set up in terms of Camel:

channel view

If we also reimplement MappingRuntime, old clumsy graphical useOneAsMany will works as well. But this is not obligatory for me.

The core idea is to smooth the shift from PO 7.5 which is final station for this evolution to Camel-4 and to decrease learning curve.