Validating Data

You validate data differently depending on the PeopleCode class that you’re using to receive the message.

XMLDoc Class Validation

You can validate incoming XML DOM-compliant messages by using the XmlDoc document type definition (DTD) that is delivered with your PeopleSoft application.

See PeopleCode API Reference: Understanding XmlDoc Classes.

SoapDoc Class Validation

You can validate SOAP-compliant messages by using the ValidateSoapDoc method in the PeopleCode SoapDoc class.

See PeopleCode API Reference: Understanding theSOAPDoc Class.

Message Class Validation

Have a message receiving process validate incoming data by:

  • Using the ExecuteEdits method in the code to invoke the definitional edits.

  • Calling PeopleCode validation built-in functions (if they already exist, for example in a FUNCLIB record, or if validation logic can be encapsulated within a small set of built-in functions) from within the receiving PeopleCode.

  • Calling a component interface or Application Engine program from the receiving process (for complex validation logic).

    This enables you to reuse logic that is embedded in the component.

The ExecuteEdits method uses the definitional edits to validate the message. You can specify the following system variables alone or in combination. If you don’t specify a variable, all of the edits are processed.

  • %Edit_DateRange

  • %Edit_OneZero

  • %Edit_PromptTable

  • %Edit_Required

  • %Edit_TranslateTable

  • %Edit_YesNo

The following example processes all edits for all levels of data in the message structure:

&MYMSG.ExecuteEdits();

The following example processes the Required Field and Prompt Table edits:

&RECPURCHASEORDER.ExecuteEdits(%Edit_Required +
 %Edit_PromptTable);

ExecuteEdits uses set processing to validate data. Validation by using a component interface or a PeopleCode built-in function is usually done with row-by-row processing. If a message contains a large number of rows per rowset, consider writing the message to a staging table and calling an Application Engine program to do set processing if you want additional error checking.

ExecuteEdits sets several properties on several objects if there are any errors:

  • IsEditError is set on the Message, Rowset, Row, and Record objects if any fields contain errors.

  • EditError, MessageNumber, and MessageSetNumber are set on the Field object that contains the error.

If you don’t want to use ExecuteEdits, you can set your own errors by using the field properties. Setting the EditError property to True automatically sets the IsEditError message property to True. You can also specify your own message number, message set number, and so on, for the field. If you use the Exit(1) built-in function, the message status changes to Error when you finish setting the fields that are in error.