Document Authorization

Database Change Management (DBCM) supports Document Authorization, using ION Workflow. Document Authorization is about approving or rejecting changes that are made to Business Objects, in a controlled way.

If a user makes changes to a Business Object in ERP Enterprise, these changes must be submitted for approval. Only when these changes are approved, the Business Object may be processed further.

Example

A user changes a Sales Order object, by modifying header data, or by adding, changing, or removing lines. The user must submit the changes for approval. After approval, the Sales Order object can be processed further.

Through DBCM, two versions of the same Business Object can exist during a certain time frame: a checked-in version and a checked-out version.

If a user changes a Business Object, automatically a checked-out version is created. This checked-out version is only visible in maintain sessions for that particular Business Object. This version is unknown to the rest of the ERP system. This checked-out version is a kind of scratch version. A user can change anything. The changes are not available to the rest of the system until the user submits the changes, and someone approves these changes. You can undo these changes, and revert back to the original version.

Administrators can use the Checked-out Objects (ttocm9599m000) session to view the objects that are currently checked out, and to perform corrective actions in case of errors. See Actions for checked-out objects and the session help.

Modeling and Deploying Document Authorization

To support Document Authorization for a Business Object, a Model must be defined using the Object Change Management modeling sessions (ttocm0101m000). A model defines for which user actions Document Authorization is supported.

A model contains multiple object types. Per object type, this information is specified:

  • Actions
  • Table relations, if the object contains data from multiple tables
  • Mappings

Infor delivers a predefined model. You can copy this model and customize it to your needs. You can choose for which Business Objects you want to use Document Authorization, by specifying this in a Deployment.

If the Model describes two Object Types A and B, and you use Document Authorization for Object Type A. DBCM does not create checked-out versions for instances of Object Type B. Instances of Object Type A are always checked-out.

Depending on the active user actions in the Deployment, one of these events occurs when changes are submitted:

  • To get approval, the LN application logic publishes a Workflow BOD to ION.
  • The object is automatically checked in.

Prerequisites

To support Document Authorization, these prerequisites must be met:

  • ION Workflow must be installed.
  • The workflow definitions that are specified in the actions of the object types must exist in ION Workflow.
  • The LN application must use the DAL2 concept. The DAL of the root table must implement these hooks:

    • on.submit()

      This hook is executed when changes that are made are submitted for approval.

    • on.recall()

      This hook is executed when the submit must be recalled. Both these hooks must publish a Workflow BOD to ION Workflow.

  • The LN application must be adapted.

Application changes

To support Document Authorization, the application must be adapted.

After a Business Object is checked-out, no changes to any related Business Objects of another Object Type are allowed. Therefore the DAL may only update tables that belong to the Business Object itself. Only during checking-in, Business Objects of other Object Types may be updated. To support this, you must use the dbcm.object.is.being.checked.in() function.

If a session can be used to change data of a Business Object for which Document Authorization must be supported. This session must specify the selected Object Type. In that way the portingset knows whether to include checked-out versions when selecting data from the database. For maintain sessions this is done automatically by the 4GL Engine, based on the main table. For update sessions, you must use these funtions to achieve this: dbcm.select.object.type() or dbcm.select.object.instance.

The session must indicate the user action that is being performed. For example, if the user presses the Release to Warehousing button, and this supports Document Authorization. The application must indicate that this action is being performed by the application logic. DBCM can then determine whether this action requires approval.

The 4GL Engine supports these standard actions through the User Interface:

  • Inserting
  • Updating
  • Deleting

Any other, application-specific, actions must be selected by the application using the dbcm.select.object.action function.

Checked-out Business Object states

This table shows the states a Business Object can have:

State Description
Draft The object is checked-out, it can be modified and any changes can be submitted. Any changes can be undone by performing a Revert to Approved in the User Interface.
Draft (Revision) The object is in the Draft state, for a second time; this state is equal to the Draft state, except that an object can only enter this state after a Recall of any submitted changes was successful.
Pending Any changes to the object have been submitted and the user must wait until the changes are Approved or Rejected. The object cannot be modified.
Recall Requested The user made a request to ignore any submitted changes, because the user, for example, wants to make more changes to the object. The object cannot be modified.
Rejected Any submitted changes to the object were not approved. The user must either make other changes and re-submit them, or perform a Revert to Approved. The object can be modified.
Approval Received Usually this state is not visible to the user. It can only be visible if somehow, after receiving an Approval, the object cannot be checked-in. In this situation an administrator must force a check-in, or discard any changes and perform a Revert to Approved. The object can be modified.
Approved Any submitted changes to the object have been Approved, and the object has been checked-in. The object can be modified.