Enterprise Software

Enhance your client's SAP applications with complex objects

Like a Dr. Frankenstein intent on development instead of reanimation, consultants often cobble together versions of different apps to produce one that's vastly improved. See how to create complex objects at the business level--without creating a monster.


When putting together an SAP application, it's not uncommon to find your client asking you to create something that's not only better than what existed before, but that also combines new-and-improved versions of different apps into one big, bad new app. Integration is, after all, one of the legs of SAP, so it's not surprising to find this complexity emerging at the business level.

For example, business documents today need to be far more detailed and comprehensive than in the past. The carefree days of simple order/invoice cycles are a thing of the past. Now there are purchase order changes, advance ship notices, promotional data, just-in-time inventory records, and many other sources of important information that matter to a company and its suppliers, distributors, customers, and so on.

The new SAP apps your client wants you to design aren't just complex systems; they require that you combine old records and standard documents into new, complex ones that will require more intricate handling than what came before. Here's a look at what's involved in creating and handling those complex objects.

Increasing complexity
What makes an object complex? Put simply, a database object (in SAP or any other ERP system) may be considered complex if it has other objects nested within. For example, suppose your client's SAP system contains database tables with product master data. A single product record in the master table might have tiered pricing (that is, a line in that table could contain an internal table.)

As you might guess, such objects must be articulately defined, and the passing of data into and out of the table requires a bit of diligence. Here's how you do it using SAP's in-house language, ABAP/4, for implementation.

Defining a complex object with SAP's ABAP/4
Complex objects are best constructed as logical combinations of simple ones. A useful complex object reduces to a handful of sensibly designed simple objects, with the relationships between them clear and reasonable. For example, we might create a customer record that incorporates a component record name. In turn, the nested name record could contain several fields: prefix, first name, MI, last name, and so on.

What this buys you is obvious: You've created a reusable component that can be plugged in elsewhere in your system, and you've simplified your maintenance considerably with a data structure that will permit easy and efficient mass updates.

This is also a great way to handle multiple occurrences of a particular data item in any database table. For example, if your customers all have multiple addresses or if your products have an array of possible prices, a nested table is the way to go.

Creating these tables is simple. In ABAP/4, you can build complex structures from elementary types (all such structures must reduce to elementary types). You define a record by bracketing it with begin of and end of, and you define a table with occurs:
types: begin of name,
              prefix(2),
              first_name(12),
             mi(1),
              last_name(25),
       end of name,
       begin of team_member,
              name type name,
              department(12),
              job(20),
       end of team_member.
data receiver type team_member occurs 0.

What's happening here is that a nested record (name) is being created as a complex type and then embedded in a higher-level complex type (team_member). You can directly address the nested table:
receiver-name-lastname = 'smith'

It's a simple matter to add a layer of complexity by making the embedded component a table. Suppose we want to add a local job history to the employee record, representing the employee's advancement. Since there may be many occurrences if the employee is a real climber, we need to make that embedded record a table:
begin of jobs,
       department(12),
       job(20),
end of jobs,
begin of team_member,
       name type name,
       work_history type jobs occurs 12,
end of team_member.
data team_members type team_member occurs 50.

Importing and exporting complex objects
Here's where the real power of complex objects kicks in. In ABAP/4, the import and export statements permit you to combine complex objects and to retrieve them (or store them) as one virtual object. As long as you use these statements correctly, SAP will keep everything straight for you, no matter how complex the individual objects and no matter how complex your virtual object.

It's important to note that you can use the power of import and export, and the virtual complex objects they enable, for both database interaction and for local application use. That is, you can create a virtual complex object by retrieving multiple stored complex objects and manipulate them in temporary storage (for more than one application, if you like, and across more than one calling level). What is particularly useful about this technique is that it allows you to manipulate disparate nested low-level tables simultaneously if required, even if they're not part of the same structure.

Retrieving a complex object to temporary storage
ABAP/4 local program storage is called ABAP/4 Memory. You can create a cluster in main memory through the simple act of assigning tables to it and giving it an identifier:
data: company_team_members like team_members occurs 50.
export company_team_members to memory id 'EMPLOYEES'.

For simplicity's sake, you can go the opposite direction using almost the same code:
data: company_team_members like team_members occurs 50.
import company_team_members from memory id 'EMPLOYEES'.

But add the following:
if sy-subrc ne 0.
       write 'Import failed.'.
end if.

Renaming objects for application program use
Renaming an object for use in the local program is easy. Suppose that in the example above, your application handles the updating of personnel records and work histories in team member records have been serviced. Here's how you'd pass a modified table back into the database:
data company_team_members like team_members occurs 50.
import latest_team_members to company_team_members from memory id "EMPLOYEES'.

When you're finished with ABAP/4 Memory, you clear it as follows:
free memory id 'EMPLOYEES'.

Handling persistent complex objects
Suppose that you're directly interacting with the database and don't need to manipulate tables in local memory. First, understand that a persistent object is one based on a permanent table that is defined as such in SAP. (The path for creating such a table is Object Browser Initial | Dictionary Objects | Create.) The name used for a table in this definition is the one you'll use for import and export.
tables empmaster.
data: company_team_members like team_members occurs 50.
export company_team_members
      to database empmaster(xx) id 'EMPLOYEES'.
And to import:
tables empmaster.
data: company_team_members like team_members occurs 50.
import company_team_members
from database empmaster(xx) id 'EMPLOYEES'.
if sy-subrc ne 0.
       write 'Import failed.'.
end if.

In this example, xx is an area identifier for a section of the referenced table. It has to be in the code, but its function of identifying a section of the table to and from which internal table data is passed is handled by the ABAP/4 runtime system. You don't need to worry about it.

The error routine included on import uses a system return code that will be 0 only if there is an object in the database table to be retrieved. A nonzero value will be returned if nothing is there.

A final word
The proactive consultant is the one who gets noticed, gets the good reference, and gets asked back. Knowing what you can do with a business document in SAP, you have a tool in your kit that can give considerable power and potential to your client's extended applications. Consider that your client may not be completely aware of the possibilities. Then, put some creative thought into how you can consolidate and extend existing applications with SAP's ability to create and efficiently store complex records and suggest these enhancements to your client.

 

About Scott Robinson

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks