Hello,

We are starting a project to integrate our Adabas/Natural system with SAP, and our approach will be to use web services enabled by EntireX for real-time integration (a SOA foundation will lie between them). Both systems to some extent perform order management, fulfillment and inventory, and financial matters (invoices, booking, etc), though SAP will also include plant systems and a third party WMS will also be in the mix.

Has anyone else done this kind of integration using EntireX with SAP or know of someone who has who would be willing to discuss with me offline on tips and gotchas?

Thanks in advance!

Regds,

Brian Johnson

Integration Server can be the middle SOA Hub.
It has both EXX and SAP adapters.
Shmuel

Sounds like webMethods IS would have made things easier, but our SOA foundation is Oracle Fusion, so we’ll have to code our own integration logic. Is there anything specifically about SAP we should know since this is the case?

Brian, I’m a bit confused. Do you want to integrate SAP (whatever that may be, SAP has tons of products/technologies) directly via EntireX with Natural? Or do you want to integrate SAP with Oracle Fusion, and then integrate Oracle Fusion via EntireX with Natural?

SAP is on the other side of the mountain it should not matter.

Connect strictly standard based (with WSDL contracts) EntireX to/from Fusion.
There is nothing in EntireX sensitive to SAP or whatever is behind Fusion.

We have at Bar Ilan university ADABAS/Natural on mainframe connecting to Oracle (stored procedures) via XML RPC server. But all we see in EXX - is pure WSDL-based SOAP over HTTP to Oracle.

In opposite direction - the Oracle hub is presumed to be able to run Java. In our case - connection to mainframe Natural is: Java EXX client, but it could be web service to EXX.

Shmuel

My reason for asking is precisely about what is “on the other side of the mountain”. We are already experienced in Natural calling web services or exposing objects as web services through the SOAP capabilities of EntireX (Designer tool and the generated artifacts, XML RPC Server, Natural RPC Server, etc.), and having the Oracle Fusion SOA layer serve as the intermediary between Natural/EntireX and the systems we integrate with (e.g., Oracle eBusiness Suite, Oracle Product Data Hub). I guess I didn’t clarify to start with, but I am certain we can integrate with any other application in this way as long as it has the same kinds of capabilities to talk to a SOA layer (no matter who the vendor is).

But SAP is new to me… with Oracle we had to deal with their AIA framework that makes their native WSDLs include self-referencing XSD schema definitions, and the incredibly long-running services that we learned to design our service calls to function asynchronously with while letting the SOA layer perform the synchronous client wait for us. After such lessons learned about integrating with Oracle, are there such lessons to be learned with SAP unique and different from what Oracle had?

Thanks,

Brian

The project that trigger my initial question was cancelled and so this went nowhere, but there is a good chance something will be kicked off soon to make me revisit. What I know now that I didn’t know before (or maybe even wasn’t true before) is that our SAP environment is / will be S/4 HANA. I believe the last couple of years were spent migrating all our various SAP installations to this platform in what we call SAP Un1ty, as Eaton acquired a number of different companies (Moeller and Cooper inclusive) that ran different flavours of SAP, with Cooper having the most advanced SAP technology in house.

That said, in researching S/4 HANA, it appears it comes with a SOA manager, so I am pretty confident we should be able to expose and consume each other’s web services with EntireX providing that functionality to our Natural environments as we have now done for other projects and service consumers.

What is still a bit troubling for me is in knowing that SAP likes to own all data and all processes, so this is coming from a business process perspective that I still have questions. If our Natural applications that perform certain order management, inventory, fulfillment, invoicing and claims functions is to integrate with an SAP application that does some of the same things and other functions as well, how do I know what is safe to build integration connectivity to that doesn’t cause redundant and potentially contradictory processes to be executed by both systems? Obviously our Natural applications are more flexible in that regard since it’s all in-house code we can look at and change, but how do I find out what SAP allows for the turning on/off or conditional settings for certain functionality that we want our Natural applications to manage?

This is more what my initial curiosity was when I first posted, but I didn’t know enough yet to really ask clearly enough and perhaps still know too little, but I can see now that different flavours of SAP existed that drove completely different integration designs and methodology (for example, Crossvision was perfect a decade ago for SAP to EntireX integration, but probably is irrelevant for S/4 HANA if Crossvision is even still available).