Action Handlers

Action handlers may be assigned to an event on the Reconcile Process or Post Type. The table at the bottom of this page describes each event handler and its parameter. It also lists the events to which the action handler may be assigned.

Ensure you have the correct service selected in the Available Services windows.
Select the Version Processing tab. Action handlers may be assigned to an event on the Reconcile Process or an event on a Post Type assigned to a node under the Post Process.
Right-click an event under the Reconcile Process or a Post Type and select Add Action Handler.

Select the newly created action handler to display the properties in the right side of the window.
- Action Name: Give the action handler any name you'd like.
- Action Handler: Select an action handler from the pull-down list. The table below describes each action handler. Only the action handlers available for the selected event are listed in the Action Handler field.
- Action Handler Description: Once you've selected an action handler, its description appears in this field. This field may not be edited.
- Parameters: This grid lists all available parameters for the action handler. The table at the bottom of this page describes the parameters for each action handler.
Click Apply to save changes and retain the Geodatabase Manager window. Click OK to save changes and dismiss the window. Click Close to dismiss the window. You will be prompted to save changes before closing.

You can modify the configuration of a service while it is running, but your changes will not be active until the service is restarted.

You can assign an existing action handler (along with its parameters) to multiple events. To do this, right-click the existing action handler and click Copy. Right-click an event and select Paste. Action handlers can be assigned (and pasted) only to valid events (see Can Assign To column in table below).

To remove an action handler, right-click it and select Delete Action Handler.

Action Handlers

Action Handler	Description	Parameters	Can Assign To	Node Type
Call Node Deleter	Deletes the Process Framework node (e.g., session or design) associated with the version being posted. In some cases, locks may persist on the version, temporarily preventing it from being deleted (e.g., after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. In both of these cases, the action handler will mark these Process Framework versions for deletion by the Orphaned Versions Cleanup Tool. Do not assign Call Node Deleter and Call Work Request Node Deleter to the same event.	None	After Post	Session or Design
Call Work Request Node Deleter	Deletes the work request associated with the version being posted. This will also delete any designs under the work request as well. In some cases, locks may persist on the version, temporarily preventing it from being deleted (e.g., after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. In both of these cases, the action handler will mark these Process Framework versions for deletion by the Orphaned Versions Cleanup Tool. Do not assign Call Node Deleter and Call Work Request Node Deleter to the same event.	None	After Post	Design
Cleanup Feeder Sync	Deletes the information from the MM_EDITED_FEATURES table after posting during Feeder Sync. This requires Feeder Manger Sync to be enabled through the Feeder Manager Configuration window.	None	After Post	Session, Plain, or Design
Delete GDB Resources	Deletes from the ArcFM System Tables, any stored data associated with the version being posted. This may include Targets tab data, stored displays, page templates, design map extent, and design data.	None	After Post	Session or Design
Delete Non Postable Features	Deletes any features or objects in the processed version corresponding to the model names configured in the Parameters section. For example, use this action handler to delete any features that should not be posted (e.g., Work Locations) from a version prior to posting it.	UseDesignID: Indicates whether the field with the DESIGNID model name assigned should be used to identify any features to be deleted. If set to True, then only features with the specified model name (ModelName param) and a DESIGNID model name matching the current design will be deleted. This parameter applies only to Designs. Default=True. ModelName: Specifies the class model name(s) used to identify objects and features to be deleted. Default=MMDoNotPost.	Before Post	Session or Design
Delete Objects By Work Function	Deletes any features or objects in the version that are present in the corresponding design and have the specified WorkFunction values. For example, use this action handler to delete any features that have a work function value other than Install.	WorkFunction: Specifies the Work Function value to be deleted. Any feature or object in a design that has a work function that corresponds with this parameter will be deleted. Default=2, 4, 8, 16, 32.	Before Post	Design
Delete Version	Deletes the version being processed from the database. In some cases, locks may persist on the version temporarily, preventing the version from being deleted (e.g., after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. In both of these cases, the Delete Version action handler will log the version into the Delete Version Queue table. The service will attempt to delete any version in this queue at the beginning of each process cycle.	None	After Post	Any
Delete Work Request Polygon	Deletes the work request polygon associated with the current version.	None	After Post: When the work request polygons ARE in the version to which you are posting. Before Post: When the work request polygons are NOT in the version to which you are posting.	Design
Email Reconcile/Post Error	Sends an email via SMTP in response to an error encountered in the reconcile or post events.	MailServer The name of the SMTP mail server. Recipient: A comma-delimited list of recipient email addresses. From: The email address of the sender. Reply-To: The reply email address. FilterErrors: This setting defaults to False, which means an email is sent out for all errors encountered. A setting of true filters out specific errors before sending an email. With a value of True in this parameters, an email is NOT sent out in the event of the following errors: VERSION_NOT_AVAILALBE, VERSION_BEING_RECONCILED, VERSION_BEING_EDITED.	ReconcileError PostError	Any
Log to Post History	Writes or updates a row in the Post History table with the name of the version being processed, the start and end times of the post operation, and the status of the operation. For example, configure this action handler on the Before Post event to write a row into the Post History table. Configure it again on the After Post event to update the row with the end time and status of the post operation. This information is visible on the Monitor tab.	None	Before Post After Post	Plain
Log to Reconcile History	Writes or updates a row in the Reconcile History table with the name of the version being processed, the start and end times of the reconcile operation, and the status of the operation. For example, configure this action handler on the Before Reconcile event to write a row into the Reconcile History table. Configure it again on the After Reconcile event to update the row with the end time and status of the reconcile operation. This information is visible on the Monitor tab.	None	Before Reconcile After Reconcile	Any
Log Session/Design to Post History	Inserts or updates a row in the Post History table and includes Process Framework information if it's available. This information is visible on the Monitor tab.	None	Before Post After Post	Session or Design
Reset Designer Fields	Updates fields on features and objects in the version according to the parameter settings. While the primary intent is to update Designer-specific fields, additional fields may be configured as well. You may add parameters to reset other fields or remove default parameters to prevent field values from being reset.	WorkFlowStatus: Enter the value used to reset this field. Default=0 WorkFunction: Enter the value used to reset this field. Default=0 WorkRequestID: Enter the value used to reset this field. Default=Null DesignID: Enter the value used to reset this field. Default=Null WorkLocationID: Enter the value used to reset this field. Default=Null	Before Post	Design
Run Feeder Sync	This updates the Feeder Manager 1.0 fields (FeederID, FeederID2, FeederInfo (without island or terminal device bits set)) in the geodatabase for the features that exist in the MM_EDITED_FEATURES table. This requires Feeder Manger Sync to be enabled through the Feeder Manager Configuration window. Note: The ParentCircuitSourceID information is not updated in the geodatabase with this action handler.	None	Before Post	Any
Run QA	Executes any QA validation rules configured for any features or objects that have been inserted or updated in the version being processed. When configured on the Data Validation event for Post Types, this action handler will enable the Validation Error event if any QA validation errors are detected. All QA validation errors will be written to the log file specified in the QALogFile parameter.	StopPost: Indicates whether the post operation should continue if QA validation errors are detected. Set the value to True to halt the post process. Set it to false to continue the process. Default=True. QALogFile: Define the location of the log file. This log file contains only QA errors. Geodatabase Manager does not currently support saving log files across a network. The path in this field must be local.	Data Validation	Any
Send Notification Email	Sends an email via SMTP. This action handler is more generic than the Email Reconcile/Post Error action handler. This action handler allows you to define the subject and body using parameters. It may be used to send an email at any point in the process.	MailServer The name of the SMTP mail server. Recipient: A comma-delimited list of recipient email addresses. Subject: Text to be included in the email's subject line. Body: Text to be included in the email's body. From: The email address of the sender. Reply-To: The reply email address.	Any event (except Reconcile and Post events)	Any
Transition Node	Useful for Post Type events related to session or design node types only. Transitions the Process Framework node related to the process version to a new state. This transition is made directly to the database rather than through the Process Framework API. Consequently, this action handler may be useful in environments where Process Framework caching behavior may not be turned off. If Process Framework caching is disabled, it is recommended to use a Process Framework task to transition the state of a node, rather than an action handler (refer to section below).	FromState: The original state of the session or design associated with the version being processed. The Value attribute must match the state in the Process Framework database and is case sensitive. No value is required in the Type field. ToState: The new state of the session or design associated with the version being processed. The Value attribute must match the state in the Process Framework database and is case sensitive. No value is required in the Type field.	Post Error After Post In Conflict Validation Error Reconcile Error	Session or Design

Process Framework Caching and the Transition Node Action Handler

By default, the Process Framework architecture caches the states of nodes that it has accessed. This is done to improve performance for the desktop Process Framework applications (e.g., Session Manager, Workflow Manager). However, this behavior may cause an undesirable effect within Geodatabase Manager.

For example, suppose a version related to a session node is processed by Geodatabase Manager, but is found to have conflicts and subsequently transitioned to a state called 'In Conflict.' On another computer, a user opens the In Conflict session, resolves any conflicts, and then resubmits the session to be posted, which includes transitioning the session from the 'In Conflict' state to a 'Pending Post' state. Depending on various circumstances, the Process Framework application instance that Geodatabase Manager uses to access session nodes may still consider that session to be in the 'In Conflict' state, because the transition was not performed within its context. This may result in some configured Process Framework tasks or action handlers to not process the version or node appropriately.

The ArcFM Solution provides a means to disable the Process Framework caching behavior using a registry key on the computer that hosts the Geodatabase Manager service. This key notifies the Process Framework to not cache node states. On a 32-bit system, install this registry key using the Disable_CSCache.reg file that is installed along with Geodatabase Manager in the following directory: \Program Files\Miner and Miner\ArcFM Solution\bin\. On 64-bit systems, you need to edit the registry subkey in this .reg file. With Disable_CSCache.reg open in a text editor like Notepad, edit the subkey [HKEY_LOCAL_MACHINE\SOFTWARE\Miner and Miner\Process Framework\Caching] to read [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Miner and Miner\Process Framework\Caching] instead. Save the file and double-click to create the registry key.

Schneider Electric recommends that you disable the Process Framework caching behavior on any machine used to host a Geodatabase Manager service.