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.

This Google Code site is for developers who are collaborating to build ZOA classes. If you are looking for more information about ZOA classes, please refer to the Project Links page here:

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.

http://groups.google.com/group/sapzoa/web/project-links

How is ZOA different to BAPIs and RFCs?

ZOA is a consistent framework for reading and writing to SAP entities, with support for SOA integration. It is:

• simple - self explanatory method and field names
• consistent - common interfaces whatever the data
• compact - only the fields you want and need
• complete - a fully implemented ZOA class can do anything
• transparent - able to log and trace calls
• extensible - every interface has parameter/value tables for stable proxies

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'?

ZOA services are more granular that BAPI services. Whilst a BAPI implements functionalisty for an entire business object, a ZOA service addresses the next level down - e.g. header, item, shedule line or business parter. This is a ZOA feature. One of the commmon ZOA methods lists related features, so it is easy to develop a complete picture of a SAP business object with minimal overhead. ZOA read functions are used on the related fatures to access whatever information is needed.

A feature is a flat structure reflecting SAP data, like Sales order header, or Purchase order item.

Features can have parents, children and siblings.

Relationships are managed using common classes and methods.

How can an interface be simple and complete?

Only very basic fields are named in interfaces More complex fields are addressed using optional parameter/value arrays GetFields method has filters to return mandatory, basic, grouped etc fields GetRelatedFeatures delivers rich hierarchical context ProposeDefaults reduces guesswork around user/config settings

Illustrative subset of methods

Here are some of the methods defined in the ZOA superclass and, if necessary, reimplemented in classes for specific features:

• SAPChange
• IsFieldValueValid
• ListProposedValues
• ListFields
• ListRelatedFeatures
• SAPRead
• SAPCreate
• IsUserAuthorized
• ListAllowedFieldValues
• SAPListIds

How will I build new features?

It will be quite easy to build new features, because the superclass does most of the hard work. The steps will be:

1. Choose a name for the feature
2. Put the basic fields into a structure
3. Create a class under the ZOA superclass
4. Register tables, fields names, keys and related features in the constructor
5. Provide some code to implement each SAP data method - the superclass does the rest