Action Handlers

Action handlers may be assigned to an event on the Reconcile Process or to a post type (under the Post Process). The table below describes each event handler and its parameter. The table also lists the events to which the action handler may be assigned.

Ensure the correct service is selected in the Available Services window.
Select the Version Processing tab. Action handlers may be assigned to an event on the Reconcile Process or under Post Process to an event for a post type.
Right-click an event under the Reconcile Process or a post type under Post Process and then select Add Action Handler.
Select the newly created action handler to display the field properties in the right side of the window.
- Action Name: Provide a name for the action handler.
- Action Handler: Select an action handler from the drop-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 select an action handler, the action handler description appears in this field. This field is read-only.
- Parameters: This list all available parameters for the action handler. The table below describes the parameters for each action handler.

Click Apply to save changes and continue displaying the Geodatabase Manager window. Click OK to save changes and close the window. Click Close to close the window. You are prompted to save changes before closing.

NOTE: You can modify the configuration of a service while it is running but your changes are only 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 the 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 (such as session or design) associated with the version being posted. In some cases, locks may persist on the version temporarily preventing it from being deleted (such as after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. The action handler marks 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 and all designs under the work request. In some cases, locks may persist on the version temporarily preventing it from being deleted (such as after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. The action handler marks 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 Manager Sync to be enabled through the Feeder Manager Configuration window.	None	After Post	Session, Plain, or Design
Delete GDB Resources	Deletes any stored data from the ArcFM System Tables 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 (such as Work Locations) from a version prior to posting it. IMPORTANT: Before deleting a non postable feature, verify the following: 1) WorkRequest polygon feature class does not use the MMDONOTPOST model name or the model name that you specified in the Model Name parameter and 2) the value UseDesignID is set to TRUE. If these values are not correct, the WorkRequest class does not use the DESIGNID field, and the action handler deletes all of the features in the WorkRequest feature class.	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 parameter) 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 (such as after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. The Delete Version action handler logs the version into the Delete Version Queue table. The service attempts 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 to. Before Post: When the work request polygons are not in the version to which you are posting to.	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 parameter, an email is NOT sent out in the event of the following errors: VERSION_NOT_AVAILABLE, VERSION_BEING_RECONCILED, VERSION_BEING_EDITED. Users can set up owner-targeted email notifications in the parameter list.	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 and 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 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: Type the value used to reset this field. Default=0 WorkFunction: Type the value used to reset this field. Default=0 WorkRequestID: Type the value used to reset this field. Default=Null DesignID: Type the value used to reset this field. Default=Null WorkLocationID:Type 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, and 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. Users can set up owner-targeted email notifications in the parameter list.	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.	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.

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

Owner-Targeted Email Notifications

The Geodatabase Manager (GDBM) email action handlers can send targeted email notices directly to the current owner of the design, session, or SDE version being processed. This is in addition to the global list of recipients specified in the Recipient parameter for the action handler.

To enable this behavior, type a new parameter for each potential owner of a design or session or SDE version, into the action handler parameter list. The Name field of each new parameter should consist of the character "@" followed by a user name. The Value should be the email address (or a comma-delimited list of email addresses) for that user.

NOTE: The name used in the Name field must match a user name in the ArcFM Process Framework (i.e., the USER_NAME field of a row in the MM_PX_USERS table) or an ArcGIS user that may be the owner of an SDE version (i.e., the OWNER field of a row in the SDE_VERSIONS table).

When processing a design, session, or version, GDBM calls upon the Send Notification Email action handler or the Email Reconcile/Post Error action handler to obtain the current owner of the design, session, or version and try to match that user name with one of the user names listed in the Name field in the parameter list. If a match is found, the corresponding email address in the Value field of the matching parameter will be appended to the email address(es) specified in the Recipient parameter for the action handler. The current owner then receives an email as the current owner of the design, session, or version currently being processed.

For a design, the current owner is established by the CURRENT_OWNER_ID field of the row in the MM_WMS_DESIGNS table that corresponds to the design. For a session, the current owner is established by the CURRENT_OWNER field of the row in the MM_SESSION table that corresponds to the session. For a plain SDE version (not a design or a session), the current owner is established by the OWNER field of the row in the SDE_VERSIONS table that corresponds to the version.

The table below is an example parameter list showing how to set up the targeted emailing behavior for the Send Notification Email action handler in GDBM. The Recipient parameter is optional, so leave this Value blank if you want to send only targeted email notices (e.g., there are no recipients that always need to be notified regardless of which design, session, or version is being processed). If the Recipient parameter is left blank and no matching user name parameter can be found for the current owner of a particular design, session, or version, then no email will be sent at all in that instance.

Name	Value
MailServer	smtp.mycompany.com
Recipient	GISManager@mycompany.com
Subject	Design posted.
Body	Nice work! But don’t be presumptuous.
From	GdbmAdministrator@mycompany.com
Reply-To	GdbmAdministrator@mycompany.com
@JSmith	john.smith@mycompany.com
@NJohnson	nancy.johnson@mycompany.com
@PWolf	peter.wolf@mycompany.com
@RHammerstein	rodger.hammerstein@mycompany.com
@RBeethoven	rollover.beethoven@mycompany.com