When I implement BAPIs, I often find myself declaring and / or ignoring all kinds of tables and structures which are not relevant to the task at hand. That’s not a problem for internal ABAP development, but external developers who are not familiar with SAP business processes can struggle to make sense of the interface definitions.
An important goal of the ZOA project is simplifying access to SAP data and processes. This will be easier if method calls can take smaller bites of the cherry, as it were, instead of dealing with an entire business object. This will reduce complexity by handling fewer components.
What is the next level down from business object, that distinguishes between headers, line items, schedule lines, business partners and so forth? Michael Seubert and Thilo Krahmer in “enterprise SOA Object & Service Operation Design part V Documentation and Naming Guideline” define the next level down as “node”. Some third party integration tools describe it as “feature”. If you have preferences or ideas about this naming convention then please share them in the comments below. For the rest of this post, I will use the term node.
Therfore a ZOA class can be defined for any data node. For example, there would be a purchase order header node class, an item node class, a plant node class, a business partner node class, an address node class and so forth.
For referencability, every node must have a unique key. Composite keys, like order and item number, are not universally supported outside SAP, so ZOA keys will comprise a single field (even if that is just a concatenation of the composite key components). Keys will be 32 bytes for compatibility with GUID and SIBFINSTID.
Reading node data
To help achieve the goal of being developer friendly, the read service on a ZOA node class can include a list of related parent, child and sibling nodes, referencing them by relationship, name and key. This list will provide the scope of any business object dynamically. Parameters will be available to restrict the list as needed for maximum efficiency in production. But at design time, when the developer is experimenting with the service, it can return the full range of related nodes, simplifying the task of identifying and accessing required components. Further detail is available for any related node with a corresponding read call.
Changing node data
Changing data at node level is very straight forward. We just identify the node using its key, and then provide a set of parameters / values to change.
Creating business objects from a set of related nodes is the biggest challenge with the node architecture. The simplest way for external systems to communicate with SAP is “stateless”. After a stateless call completes, SAP forgets all about it – keeping no record of what just went on (ie state). There are already sophisticated stateful protocols for accessing SAP data. ZOA’s goal is simplicity, so this constrains us to use stateless service calls. But to construct a business object with many nodes using separate calls, we must be able to track progress.
Within the NetWeaver ABAP stack there is no issue about state. We can start with any node, use an “attach” service to add parents, children and siblings, and then call a “save” service to update the system. The only complication there is transitioning from temporary to persistent keys.
Exactly the same mechanism can be used for external stateless calls, by making use of SAP’s persistent class objects to simulate stateful processing using stateless calls. A create service puts the new node into persistent storage in SAP and assigns a temporary unique key (using GUIDs) which is returned to the caller. This key is then used in subsequent calls to reference the node.
Now the developer can build up the new object by creating other nodes and linking them together by referencing their temporary keys. Once all the nodes have been created and linked, the save service is called.
The save service can be called from any node, and it will automatically iterate for related nodes. The service returns a list of temporary keys, alongside the new peristent keys assigned by the system.
This blog communicates some foundational design principles for ZOA classes. In the spirit of community projects, please feed back if you have any strong thoughts or reservations about the proposed approach.