If the application service defines a DATASET (static ProDataSet) parameter, you must create a ProDataGraph that at least represents an empty ProDataSet and contains the meta data (ProDataGraphMetaData) that describes the temp-tables and data-relations defined for the ABL static ProDataSet. There must be one ProDataObjectMetaData object for each temp-table and one ProDataRelationMetaData object for each DATA-RELATION object defined by the static ProDataSet. So, the meta data in the ProDataGraph must match the schema of the static ProDataSet in every particular.
Note: While you must define a ProDataGraph with all the meta data required to map a static ProDataSet schema, you can tell OpenEdge not to send temp-table schema information to the application server in order to optimize data transfer over the network. For more information, see the setNoSchemaMarshal() method in ProDataObjectMetaData class.

If the application service defines a DATASET-HANDLE (dynamic ProDataSet), you can pass a ProDataGraph with any or no meta data, including any or no ProDataRelationMetaData objects. As a minimum, you can pass a ProDataGraph with empty meta data (an empty ProDataGraphMetaData object), which produces an Unknown value (?) in the input DATASET-HANDLE. However, in practice, you must pass a ProDataGraph with meta data that represents the ProDataSet schema expected by the application service. So, most of the time, the programming for a ProDataGraph that maps to static or dynamic ProDataSet is identical.

For more information on the differences between static and dynamic ProDataSets, see OpenEdge Development: ProDataSets.

For a typical application, the general procedure for preparing a ProDataGraph for input is a two step process.

To prepare a typical ProDataGraph for input:

  1. Create and initialize a ProDataGraph object with its meta data.
  2. Create and add ProDataObject instances to the ProDataGraph.