Document Authorization
Database Change Management (DBCM) supports Document Authorization, using ION Workflow.
If you make 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
You change a Sales Order object, by modifying header data, or by adding, changing, or removing lines. You 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 you change 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 not known to the rest of the ERP system. This checked-out version is a kind of scratch version. You can change anything, but the changes do not become available to the rest of the system. You must submit the changes, and someone must approve 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. They can perform corrective actions in case of errors.
Modeling and Deploying Document Authorization
To support Document Authorization for a Business Object, a Model must be defined using the Models (ttocm0101m000) session. 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. 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 Document Authorization for Object Type A is used. Checked-out versions are not created by DBCM 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 this 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 to achieve this, you must use one of these functions:
dbcm.select.object.type()
dbcm.select.object.instance
The session must indicate the user action that is being performed. For example, if you click
, 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:
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. |