When an entity view is defined in the Import or Export view subset, the Supports Entity Action option specifies whether the view is transient or persistent.
A transient entity view does not support the entity actions CREATE, READ, DELETE, or UPDATE. Transient views can be modified by MOVE and SET actions. Repeating group views always are transient. Transient is the default for entity views in the import, export, or local view subset.
A persistent entity view allows entity actions to be performed on the designated view. All rules that apply to entity action views apply to persistent entity views. Persistent views can be thought of as database buffers.
Use persistent views when multiple Action Diagrams require access to the same physical data record, as in batch processing.
Support for entity actions reduces the need for multiple READs of the same entity action views within a process. After the entity action view is read, a persistent view may be passed to subordinate action blocks. This means that a Procedure Step can perform a READ and pass the persistent view to an action block that performs an UPDATE action. A lock on the database record is released at the end of the Procedure Step. The subordinate action blocks may perform an UPDATE action on a received persistent view.
The following example shows persistent views in a Procedure Step and an action block:
Procedure Step:
MAINTAIN EMPLOYEE IMPORTS:... EXPORTS:... ENTITY ACTIONS: Entity View employee name number CASE OF COMMAND CASE read USE AB_READ_EMPLOYEE WHICH IMPORTS... WHICH EXPORTS output_employee employee CASE update READ employee USE AB_UPDATE_EMPLOYEE WHICH IMPORTS employee . . Action block: AB_UPDATE_EMPLOYEE WHICH IMPORTS employee . . Action block: AB_UPDATE_EMPLOYEE IMPORTS: Entity View input_persistent employee (mandatory, persistent, locked . . IF input_persistent employee IS POPULATED UPDATE input_persistent employee
Consider this example to understand the benefit of persistent views. An Action Diagram READ_EMPLOYEE performs an initial READ of an entity occurrence. The entity action view in the initial Action Diagram is matched to an import entity view in a USEd action block where an entity action is performed. The receiving import entity view is designated persistent, exported, locked.
Indicates entity actions can be performed on the view.
Indicates the import entity view can be modified. Data can flow out of the action block without the need to explicitly move the data to an export view.
Indicates the view does not need to be READ again.
To be used for entity action statements, import views must be both persistent and used as both input and output. Then, import views can be used in the following cases:
Only persistent entity views and entity action views can be used in IF statements that test whether the view is populated or locked. For more information about locked occurrences, see the next section.
Downstream Effects: There is a performance advantage to be gained by using persistent views that are exact matches. Two view structures are exact matches when they contain the same entity view and the same attributes in the same order.
If an entity action view or a persistent view is matched exactly to a persistent view in a subsequent action block, then all references between the two are handled by address passing. View data is not moved to the called action block.
Matching views exactly is quicker than actually moving the data and having two copies of it. Working storage is built in the calling Action Diagram for the view and Linkage section (only) copies of the "database buffer" are built into the called action block.
The exact match performance consideration also applies to transient views. Exported on Import Views and Imported on Export Views eliminate the overhead of extra views. SETs and MOVEs to attributes in the import view are allowed, and export views are not initialized upon entry.
|
Copyright © 2014 CA.
All rights reserved.
|
|