The DOM Object and DOM Table

Adobe Document Services (ADS) provide a range of functions for creating and editing PDF forms and documents.

 

The PDF dDocument object includes an application programming interface (API) that you can use to implement ADS functions in the familiar ABAP Workbench environment.

 

The methods of the PDF Document object are split into different categories:

• Constructor Method and Initialization
• SET Methods for Setting Attributes and Data
• SET_TASK Methods for Specifying Tasks
• Central EXECUTE Method for Starting ADS
• GET Methods for Providing ADS Data and Output
• Other Methods (GET_VERSION_INFO, IS_SSL)

 

This categorization improves performance when communicating with ADS. All information about the SET methods is gathered first. ADS then only needs to be called once, using the EXECUTE method.

 

The EXECUTE method also makes sure that the PDF Document object receives the required data from ADS.

 

You can use the GET methods to call this data.

 

The significant method in the example above is get_data. This method returns the data stored inside a form.

 

The GET_DATA method returns the data hold inside the form in XML notation (see figure).

 

The ABAP Debugger offers a special tool for visualizing the data. Select the SINGLE FIELD tool and switch to XML BROWSER to analyze the XML hierarchy.

 

If the offline form data was changed by the user before, the changed fields should be seen now.

 

During development, this is a good opportunity to control if this process step works.

 

After receiving the data with the method GET_DATA the XML stream has to be parsed and converted to something more familiar.

 

You can use the methods of the class CL_IXML_MINI to do this.

 

The parser object offers a service called PARSE_STRING that retrieves the famous DOM object. (Remember the figures on the DOM architecture before.)

 

In this case, you can now see the data DOM in the variable LT_DOM. This is a perfect control mechanism to analyze this internal table in the ABAP Debugger.

 

The figure shows the data DOM with all the user's offline changes.

 

The NAME column holds the form field names. The VALUE column contains the values that have been partially changed by the user (offline).

 

The PARENT, FIRSTCHILD, and NEXTSIB columns represent the hierarchical logic of the DOM:

• The parent object of the FIRSTNAME field has the GID number 54. It is the IS_ADDRESS field (in this example).
• The parent object of the LASTNAME field also has the GID number 54. It is the IS_ADDRESS field (in this example).
• The first child object of the IS_ADDRESS field (which is the structure itself) has the GID number 55. It is the PERS_NO field (in this example).
• After the IS_ADDRESS structure, the next element in the DOM has the GID number 176. See the NEXTSIB column.

 

Those special technical columns point to each other to represent the hierarchy of the DOM.

 

The content of the DOM can be parsed via a loop statement, and all necessary data can be transferred to a special two-column table.

 

This makes further processing steps easier.

 

In this special example, the two-column table LT_NAME_VALUE is looped and all necessary fields are transferred to the LS_ADDRESS structure (type BAPIADDR3).

 

Afterward, BAPI_USER_CHANGE stores the extracted form data in the database.