Load and validate data

After preparing and packaging the HDL files, submit the ZIP file for processing and monitor both the import and load stages. Once processing completes, verify the resulting application data and reconcile the outcome against the expected source data.

Import and load the file

Import the packaged ZIP file from the Data Exchange work area when performing an interactive load. Monitor the resulting data set until both import and load processing are complete.

For an interactive load:

  • Navigate to My Client Groups > Data Exchange.
  • Open Import and Load Data.
  • Select Import File.
  • Select or drag your ZIP file.
  • Submit the load.
  • Refresh the data set until import and load processing completes.

Monitor both stages separately:

  • Import Status — whether the file has been parsed and imported into HDL staging.
  • Load Status — whether the imported logical objects were written successfully to the application.

Also distinguish:

  • Total Lines — physical data lines;
  • Total Objects — logical business objects assembled from those lines;
  • Failed Objects — logical objects that failed to load.

A complex Worker object, for example, can consist of many file lines but still represent one logical object.

For failed imports or loads, see Review, correct, and reload failed HCM Data Loader records.

Validate the application outcome

A successful HDL processing status confirms that HDL processed the submitted data successfully.

It doesn't always prove that the broader business process is complete.

After significant loads:

  • validate representative records in the application;
  • reconcile expected source counts or totals;
  • use supplied source-reference information where appropriate;
  • complete any required object-specific postload processes.

See:

  • Validate and reconcile application data after a bulk load
  • Understand, configure, and control postload processing

File Authoring Checklist

Before submitting a file, confirm:

  • You're using the correct business-object .dat file name.
  • Every component has exactly one appropriate METADATA definition.
  • Every data line uses the correct discriminator.
  • Each record is uniquely identified.
  • Every child record identifies its parent.
  • Foreign-object references use a supported key type.
  • Source-system owner values are registered where source keys are used.
  • You're using MERGE for both creates and updates.
  • The object's Supported Actions permit the intended create, update, or delete.
  • Only changed attributes are supplied for normal updates.
  • #NULL is used where an existing value must be cleared.
  • No logical record has conflicting MERGE and DELETE instructions.
  • Any SET instructions appear before the first METADATA line.
  • Dates, numbers, lookups, and translated values use the correct format.
  • Source-reference values are included if they'll help with reconciliation.
  • ZIP packaging matches the scenario: one business object per ZIP for new-file-shape testing or very large single-object migration loads; multiple related business-object files together where appropriate.