Developing business objects using dynamic transaction

The Dynamic Transaction function module is a mapping tool and dynamic code generator. It uses SAP's Call Transaction API to get data into an SAP application. Also, it stores static definitions of Batch Data Communication (BDC) sessions by combinations of object and verb. Before the BDC data is passed to a Call Transaction, the business object attribute values are mapped into the BDC session. At the completion of the call transaction, the resulting key value is set in the appropriate value of the business object, and all messages from the call transaction are logged.

The Dynamic Transaction function module builds a BDC session to do a call transaction by combining the BDC defined in the Dynamic Transaction table, /CWLD/WIZ_IN, and the values from the incoming business object. When the Dynamic Transaction function module is called, the following steps are performed:

  1. All entries are retrieved from /CWLD/WIZ_IN, where:
    object name = objectName and verb = objectVerb
     
    
  2. Field input values are mapped from the business object into the BDC session based on the attribute name.
  3. BDC sessions are processed using Call Transaction.
  4. Key values are captured, Call Transaction messages are logged, and the key is set in the business object.

Tips

Composing a BDC session for a business object

Composing a BDC session requires an understanding of an SAP transaction's design. An SAP transaction allows the same data to be input in various sequences and on different screens. Typically each sequence or flow exposes additional functionality. As a result, certain data validation and input field requirements occur on some screens, but not on others. The challenge is to find the sequence that does what you need with the least amount of effort. A simple BDC session is more stable than a complex BDC session.

An SAP transaction may behave differently when accessed using the Call Transaction method in a background process instead of executing online. For example, different or additional screens may appear or input fields may reside on screens different from those your online investigation revealed. The discrepancy occurs because the transaction's controlling code may dictate different behavior when executed in the background from that executed online. As a result, your online test may work when reprocessing a failed object event as you step through the transaction; however, the connector consistently fails when processing the same object. If this occurs, modify the BDC so that it processes in the background. If you modify the BDC, you may encounter cases where the BDC processes in the background, but fails when processed online.

The BDC you define in the Dynamic Transaction table is static. It cannot react during the transaction if certain input data causes other screens to pop up or other fields become mandatory during runtime. Proper investigation of a transaction's configuration is important to be able to predict consistent behavior. Experiment several times with the transaction; repeated behavior can become your guideline.

Once you have determined the screen flow, follow the steps below and document the information you gather in a spreadsheet.

  1. Go to the transaction that supports your object and identify the transaction code.
  2. Identify the BDC elements for the screen and input fields you require.
  3. Identify the menu command you need to continue processing to the next screen.
  4. Repeat steps 2 and 3 for each screen required.
  5. Conclude by noting the command to save the transaction.

Table 14 describes the column names for Dynamic Transaction table /CWLD/WIZ_IN.

Table 14. /CWLD/WIZ_IN table entries for dynamic retrieve

Field name Description When used Technical name
Object name IBM WebSphere business object name Always OBJ_NAME
Verb Verb (Create, Update, Delete, or Retrieve) Always OBJ_VERB
Counter Counter Always POSNR
Program Program associated with a screen BDC screen identification PROG_NAME
Screen number Screen number associated with a screen BDC screen identification DYNPRO
Start Specifies a new screen BDC screen identification DYNBEGIN
Screen description Free text description of screen, field, or command User discretion SCR_DESCR
BDC field name BDC input field name BDC input fields FNAM
Field name in business object Attribute in the IBM WebSphere business object to supply the input value BDC input fields SOURCEFLD
Default value A static default value to use if no entry is provided in the IBM WebSphere business object or if using BDC_OKCODE, because it is the command value A value might not always be passed in and it is mandatory for the transaction DEFLT_VAL
SY Field name A dynamic system field to be used as a default value (for example: DATUM) A value is not passed in or should be determined by SAP system fields SYFIELD
Return A number between 1 and 4, that identifies which system message field returns the key value at transaction completion (SY-MSGV#) A business object key attribute that should receive the key value RETURNFLD
Length Character length from the zero position of the attribute value that should be used for input Relevant only when using an attribute that contains a composite value LENGTH

To define or modify a business object's metadata (transferring information to /CWLD/WIZ_IN):

  1. Go to IBM CrossWorlds Station (transaction /n/CWLD/HOME).
    Important:
    You must log on to the SAP system in English when using IBM CrossWorlds Station to generate business object definitions or ABAP handlers. The CrossWorlds Station log is available only in English.
  2. Click the Development tab.
  3. Click the Modify BO Metadata button in the Transaction based - Inbound section.

Defining the metadata for the business object is simple. For each screen, the first entry identifies the screen, subsequent entries identify the input fields, and the last entry must be a command. This grouping repeats for each screen.

The figure below shows the Dynamic Transaction table for a SAP4_CustomerMaster business object to create a customer (transaction XD01).

Figure 16. Dynamic transaction for SAP4_CustomerMaster create business object

Using the Counter column as a line number for discussion, step through the SAP4_CustomerMaster example.

100
Begin with screen number 100 of program SAPMF02D. This is a new screen, the first, so it is flagged in the Start column.
110
On screen 110, use the value from the Customer_account_group attribute in the business object, and add it to the BDC field name column (the value is RF02D-KT0KD). Specify the default value as 0001. If the Customer_account_group attribute contains CxIgnore, then the BDC field name column receives the default value 0001
120
The Customer_Account_Number attribute is the key value, so it is not set during the Call Transaction. SAP assigns the key value internally and makes it available only after the transaction is successfully posted. For this reason, leave the BDC field name column blank, but include an entry in the table because the Customer_Account_Number attribute must be set with this key value when it is returned at the conclusion of the Call Transaction. Also enter the word RETURN in the Program column for CustomerNumber.

Depending on the transaction, SAP returns the key value in one of four possible fields: SY-MSGV1, SY-MSGV2, SY-MSGV3 or SY-MSGV4. To specify that you want the return value set in a particular attribute, enter a number, 1-4, in the Return column. This number corresponds to the SY-MSGV# field containing the key value. For example, Figure 16 illustrates a 1 in the Return column, which indicates that SY-MSGV1 contains the Customer Number.

130
You are finished entering the necessary values for the first screen, so enter a command, /00, in the Default Value column to simulate pressing the Enter key. This takes you to the next transaction screen. Commands are entered in the screen input field, BDC_OKCODE, which is where you enter in a transaction code.
140
At this point, you are at the next transaction screen. Enter the address information. Since it is a new screen, flag it in the Start column. In this example, the second screen is associated with the same program as the initial screen, and only the screen number changed from 100 to 110. This is not always the case.
150 -210
Use the values from the Name_1, Sort_field, City, P_0_Box_postal_code, Country_key, Language_keys, and Post_office_box attributes in the business object, and add corresponding values to the BDC field name column.
220
Similar to line 130, processing for this screen is complete. However, rather than simply simulating the Enter key, enter the command value UPDA to save the transaction. This takes you to the next transaction screen.
230
At this point, you are at the third transaction screen, so flag it in the Start column. Because your business object does not require data from this screen, you will complete processing for this screen in the next line.
240
Similar to line 130, processing for this screen is complete. Enter the command value /00 to simulate pressing the Enter key. This takes you to the final transaction screen.
250
At this point, you are at the final transaction screen. Flag it in the Start column.
260
Similar to lines 150-210. Use the value from the business object attribute, Transport_zone_to_which_or_from_which_the_goods_are_delivered, and add its corresponding value (KNA1-LZONE) to the BDC field name column.
270
Similar to line 220, processing for this screen is complete and the transaction is complete, so enter the command value to save, UPDA. This is the last action the Call Transaction API receives.
280
The final entry for any business object is always the specification of the transaction code. The keyword TCODE goes in the Program column and the transaction code goes in the BDC field name column.

This completes the definition of the BDC Session for the SAP4_CustomerMaster business object.

If a call transaction returns an error message when it fails, you could have one of the common errors described below.

Using the inbound wizard for dynamic transaction

The Inbound Wizard records your navigation, actions, and field inputs in a transaction when you click the first field or change screens. The recorder picks up every action that occurs, but not everything you see. For example, when the initial screen first appears, the recorder captures the initial call to the transaction, but not all of the input fields that appear on that screen. If you want to be able to use an input field, you must enter some data into that field. Also, even though an input field may contain default data, that data is not picked up unless it is manually entered.

To create a new WebSphere business object definition:

  1. Go to IBM CrossWorlds Station (transaction /n/CWLD/HOME).
    Important:
    You must log on to the SAP system in English when using IBM CrossWorlds Station to generate business object definitions or ABAP handlers. The CrossWorlds Station log is available only in English.
  2. On the Development tab, click the Inbound Wizard Button.
  3. Enter the following information:
  4. Click Record.
  5. Step through the transaction that supports your business object functionality. Use all necessary fields and screens. When you are finished, save your transaction.
  6. Choose the components that you want to include as metadata in your business object. Place your cursor on the component, and then click the Select/Deselect sub-tree button (F9). By default, all components are selected.
  7. Generate a new dynamic object or source code.

Copyright IBM Corp. 1997, 2003