If you have a comment on this topic, contact Aptify Documentation. If you want to return to the Aptify Community Site, please click here.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

The following event definitions are delivered with the standard installation of Aptify. They appear in ID order based on ID assignments in a standard Aptify installation.

  • BeforeSave: Called when a user creates a new record or updates an existing record and clicks one of the Save buttons. Event executes prior to a record save's validation routine and the data being inserted/updated in the database. Typically, this event definition is only useful if validation occurs within the Process Flow. Otherwise, you may want to consider using the BeforeCommitTransaction event (described below) instead.

  • AfterSave: Event executes when user creates a new record or updates an existing record and clicks one of the Save buttons. Event only executes after data is successfully inserted/updated in the database. If the Insert/Save commands fail, this Event does not execute.

  • BeforeValidate: In some cases, an organization may want to use Aptify's Process Pipeline functionality to impose validation logic to the system rather than having to write an organization-specific entity object or a validation script for one or more Entity Fields. In order to support these types of process flows, Aptify provides the BeforeValidate and AfterValidate event definitions. These are Entity-scoped events tied to the Aptify Generic Entity. The Before Validate event is fired before an entity's standard validation logic is process and the After Validate event is fired after an entity's standard validation logic is processed. When a process flow is tied to one of these events, the Process Flow Engine determines if a record passes or fails validation based on the process flow's result: Success or Failed. Note that this differs from other types of events where a Failed result typically indicates that the process flow failed to execute. Keep in mind the following important points when working with validation process flows that fire using the BeforeValidate or AfterValidate event:

    • The validation events support a ValidationMessage property so a process flow designer can specify the text of the error message that appears when validation fails (the system uses the ValidationMessage as the LastError and LastUserError in the Aptify Generic Entity). A validation process flow can support the following outcomes:
      • If the process flow's result is a Success result code and the ValidationMessage property is empty, then the validation was successful.
      • If the process flow's result is a Failed result code and the ValidationMessage property has a value specified, then a message box appears to the end user displaying the ValidationMessage text.
      • If the process flow's result is a Failed result code and the ValidationMessage property is empty, then the following generic message is displayed when validation fails: Validation has failed but no information about the failure has been provided.
      • Note that the fourth option where a process flow's result is a Success result code and the ValidationMessage property is not empty will result in a validation failure and the validation message is displayed. However, this is not an expected outcome since a validation failure is expected to correspond to a process flow failure.

    • The validation in the Aptify Generic Entity will not proceed if the BeforeValidate Event fails (ResultCode of false or Failed). Therefore, the AfterValidate Event will not be fired if the BeforeValidate Event fails.

    • Unlike other Aptify delivered events that only fire for top-level entities, the BeforeValidate and AfterValidate events fire for Sub-Type entities. In these cases, the system validates sub-type records (and fires the event) twice: once when the record is closed (for example, when a user clicks the OK button) and a second time when the top-level entity record is saved.

  • AfterValidate: See the description for the BeforeValidate event definition earlier in this section for details.

  • BeforeRecordCreated: Event executes when user creates a new record (but not when user updates an existing record) and clicks one of the Save buttons. Event executes prior to the data being inserted/updated in the database.

  • AfterRecordCreated: Event executes when user creates a new record (but not when user updates an existing record) and clicks one of the Save buttons. Event only executes after data is successfully inserted into the database. If the record creation fails, this Event does not execute.

  • BeforeRecordDeleted: Event executes when user chooses to delete a record, but prior to actual removal of data from the database.

  • AfterRecordDeleted: Event executes after the record is successfully deleted. If record deletion fails, this Event does not execute.

  • BeforeRecordUpdated: Event executes when user updates an existing record (but not when a new record is created) and clicks one of the Save buttons. Event executes prior to the data being inserted/updated in the database.

  • AfterRecordUpdated: Event executes when user updates an existing record (but not when a new record is created), after data is successfully updated in the database. If the update to the record fails, this Event does not execute.

  • BeforeAsyncTaskRun: Event is triggered before the Process Flow in a Process Flow Runs record is executed.

  • AfterAsyncTaskRun: Event is triggered after the Process Flow in a Process Flow Runs record is executed.

  • BeforeCommitTransaction: Event is triggered before committing a transaction to the database. If a process flow responding to this event returns False (fail), the transaction rolls back. If a process flow responding to this event returns True (success), the transaction commits to the database, barring any other errors that would cause a rollback. This Event executes after the spCreate stored procedure has run for a top-level record but before the transaction is closed and before sub-types records are committed to the database.

  • Order Shipped: Event is triggered after the Order Status of an Orders record is changed to Shipped and the record is saved. Specific to the Orders entity.

  • BeforeLoad: Event executes just before a record is loaded into the Generic Entity Object.

  • AfterLoad: Event executes after a record is loaded into the Generic Entity Object.

  • After Process Flow Saved: Event is triggered after a Process Flows record that has Compile Mode set to Compiled and Status set to Incomplete is saved. Specific to the Process Flow entity.

  • BeforeConflictSaved: This event fires just before a Pending Changes record with Type set to Replication Conflict is saved. This event is only applicable to the Pending Changes service. This definition is reserved for future use.

  • AfterConflictSaved: This event fires just after a Pending Changes record with Type set to Replication Conflict is saved. This event is only applicable to the Pending Changes service. This definition is reserved for future use.

  • BeforeConflictPosted: This event fires just before a Pending Changes record with Type set to Replication Conflict is posted. This event is only applicable to the Pending Changes service. This definition is reserved for future use.

  • AfterApprovalRequestSaved: This event fires just after a Pending Changes record with Type set to Approval Request is saved. This event is only applicable to the Pending Changes service. This definition is reserved for future use.

  • AfterConflictPosted:This event fires just after a Pending Changes record with Type set to Replication Conflict is posted. This event is only applicable to the Pending Changes service. This definition is reserved for future use.

  • BeforeApprovalRequestSaved: This event fires just before a Pending Changes record with Type set to Approval Request is saved. This event is only applicable to the Pending Changes service. This definition is reserved for future use.

  • CampaignListStatusChanged: This event fires whenever a Campaign List Detail record has its status changed (for existing records only).

  • CampaignDocStatusChanged: This event fires whenever a Campaign Documents record had its status changed. This will be fired for both new and existing records.

  • CampaignStatusChanged: This event fires whenever a Campaigns record had its status changed. This will be fired for both new and existing records.

  • Expo Order Shipped: This event fires whenever an Order that contains an Order Line for one or more Expo products is shipped. It is based on the Order Shipped Event Definition, and it is only applicable to the Orders entity.

  • BeforeSendMessage: This event fires before a message is sent via the Messaging Engine. See the Capturing Message Details from a Message Run for Use in  a Process Flow section in the Bulk Messaging Configuration topic of the Aptify Administration Guide for information how an organization can use this event to fire a process flow.

  • AfterSendMessage: This event fires after a message is sent via the Messaging Engine. See the Capturing Message Details from a Message Run for Use in a Process Flow section in the Bulk Messaging Configuration topic of the Aptify Administration Guide for information how an organization can use this event to fire a process flow.

  • AfterOrderSaveCompleted: This event fires after an order has completely saved. This event is only applicable to the Orders service.

  • AfterOrderCreateCompleted: This event fires after a new order has completely saved. This is only fired for new orders. This event is only applicable to the Orders service.

  • AfterOrderUpdateCompleted: This event fires after an existing order has completely saved. This event is not fired for new records. This event is only applicable to the Orders service.
  • No labels

Copyright © 2014-2017 Aptify - Confidential and Proprietary