Welcome to the ZOA Wiki pages!
ZOA is an open-source integration framework for SAP NetWeaver. It is intended as a simple, consistent alternative for applications that are not suitable for existing BAPIs, or for bespoke development. ZOA stands for developer oriented architecture.
The ZOA Wiki pages are for internal and external developers who want to consume existing ZOA classes or develop new ones. If you are an experienced SAP ABAP developer and want to contribute to the ZOA project, please apply to join ZOA developer group.
The project is in its early stages, and the current source code is illustrative only. A stable release of the framework, suitable for production proxy development, is planned for June 2009.
What is ZOA?
ZOA is an open-source integration framework for SAP Netweaver. ABAP developers can wrap the ZOA framework around new and existing SAP functionality, giving external developers a simple, consistent integration experience, regardless of the underlying data types. The ZOA framework anticipates many common development and maintenace headaches, and brings harmony to the integration process.
Benefits of using ZOA's consistent framework
Reduced development times - easy to find, intuitive to use, meaningful messages, traces and logs
Low-impact enhancement - easily incorporate new functionality
Pre-emptive messaging - propose default values, list allowed values, related features, validate field entries, test user auth.
Extensible - parameter / value arrays for stable interfaces and proxies
What are "features'?
SAP data is published through the ZOA framework as features. A ZOA feature is a flat structure more granular than SAP Business Objects like sales orders or purchase orders. Examples of ZOA features are Sales Order Header, Business Partner, Purchase Order Item, Schedule Line, Plant, etc. Features can have parents, children and siblings. They are managed using common classes and methods.
ZOA provides a consistent set of methods to read and maintain features. For any feature these include:
ZOA is built from a superclass which implements shared functionality and enforces consistent methods and interfaces.
Each feature is implemented as a class descendant from the superclass.
Each feature has a corresponding function group with remote function modules to expose the class to the outside world. By abstracting the function interfaces they can be easily changed without affecting the underlying class logic.
In principle, ony a small number of essential fields are explicitly referenced in the interface. The rest are passed as parameter/value pairs, minimising the impact of changes on proxy deies and other infrastructure.