Each time you save a new entity (including sub-types), Aptify automatically generates four Process Components that create, read/load, update, and delete records for that entity. Since each component is tailored for a specific entity, developers can quickly and easily incorporate these components as steps in process flows.

Each component corresponds to a piece of generic system functionality that accepts the entity's name as an initialization parameter (specified in the Init Data field). In addition, Aptify automatically populates the Input Properties for the Create and Update components to include all of the fields in that entity.

If an entity does not have these components already generated, you can regenerate the entity, which will then generate these components. See Regenerating an Entity for information on how to regenerate an entity.

The following is an overview of the four components:

• Create [Entity Name] Record: This component creates a new record for the designated entity. The Input Properties Tab specifies all of the fields in that entity and a SaveRecord flag (which you set to Yes to save the record immediately and No to defer the save function). Fields required to successfully save a new record are marked as Required properties. For sub-type entities, the parent entity's GE object is also included as an Input Property. The Output Properties Tab specifies a GE object and Record ID that can be passed into other steps/processes.
  
  
• Load [Entity Name] Record: This component loads/reads an existing record for the designated entity. The only Input Property for this type of component is RecordID. For subtype entities, the Input Properties are the parent entity's GE object and the sub-type record's Sequence. A developer can use this component to load a specific record into the Process Flow's context object. The Output for this type of component is a GE object.
  
  
• Update [Entity Name] Record: This component updates an existing record in the designated entity. The Input Properties Tab specifies all of the fields in the entity, the RecordID, a SaveRecord flag, and a GEObject. For sub-type entities, the Input Properties include the fields in the sub-type, the parent entity's GE object and the sub-type record's Sequence. The Output Properties Tab specifies a GE object and Record ID that can be passed into other steps/processes.
  
  
• Delete [Entity Name] Record: This component deletes an existing record for the designated entity. The Input Properties Tab specifies a RecordID and a GEObject. For sub-type entities, the Input Properties are the parent entity's GE object and the sub-type record's Sequence. There are no Output Properties for this type of component.

CRUD Best Practices

• When designing a process flow that operates on an sub-type entity using one of the CRUD components, you need to pass in the GEObject for the sub-type record's parent via the Context Object to the sub-type component's step. You can do this in one of two ways:
  • If an event from the parent record fires the process flow, you can specify the GEObject as an Input Property for the Process Flow. Then, pass in the parent record's GEObject as part of the Event Handler.
  • If an event in an unrelated entity fires the process flow, use the top-level entity's Load component to load the desired record and then pass its GEObject into the Context Object (GEObject is an Output Property for the Load component). Once in the Context Object, you can specify the parent GEObject as an Input Property for the sub-type component's step.
    
    
• When designing a process flow that uses CRUD components, consider the frequency and impact of save operations, and try to minimize the number of save operations for best performance.
  
  
• For example, If a process flow creates a subtype record in a top-level record based on a change in that top-level record, use a before save event as the basis for the Event Handler. Then, within the sub-type component step, set the SaveRecord input property to No for a deferred save. In this case, the toplevel record, with any applicable sub-type record changes, is saved after the process flow has executed.
  
  
• Continuing from the example above, consider the ramification of the following designs for a process flow that creates a new sub-type record when a new top-level record is saved:
  • Event: BeforeRecordCreated 
    Step SaveRecord Input Value: No 
    Result: Process Flow fires before record is saved and creates a sub-type record. The Save is deferred until after the process flow completes. There is one save operation and one Record History entry associated with this transaction.
    
    
  • Event: BeforeRecordCreated 
    Step SaveRecord Input Value: Yes 
    Result: Process Flow fires before record is saved and creates a sub-type record. The process flow attempts to save the sub-type record to a top-level record that doesn't exist yet, creating an invalid state and an error.
    
    
  • Event: AfterRecordCreated 
    Step SaveRecord Input Value: Yes 
    Result: Process Flow fires after record is saved and creates a sub-type record, followed by another save operation to save the sub-type record. This operation is successful but two save operations occur (and two Record History entries) when one would have sufficed. Also, if the designer used the AfterRecordUpdated event in place of AfterRecordCreated in this scenario, Aptify would enter an infinite loop since each sub-type save would fire the process flow, which would create another sub-type record, etc.
    
    
  • Event: AfterRecordCreated 
    Step SaveRecord Input Value: No 
    Result: Process Flow fires after record is saved and creates a sub-type record. At some point, another save would be required to save the sub-type record, typically by another step in the process flow.