To help avoid problems, this section provides some pointers on how to bring an action tree from concept to practice.

Assume that you have created an action tree that stores messages from Exchange to your repository:

This action tree has intentionally been created with some errors to show how to troubleshoot it.

It is highly recommended to Validate the action tree after creating it and entering settings to the nodes. This automatic check cannot find all problems with an action tree, but it does tell you when an action tree will prevent an instance from starting.

Click Validate in the menu on the left. The following image appears:

This is a general error message that tells you something went wrong during action tree validation. Navigate to the instance log directory in a file browser and open the newest folder created there.

Information: A more specific error message may appear here. However, it is recommended to proceed as described below regardless of the specific error message.

Open ELOxc_[timestamp]_Main.log in a text editor. Scroll through the file until you reach a line like the following:

When the Validate function is run and whenever an instance is started, each action tree (even inactive action trees) is run through and checked for errors. Once an error is found, validation stops for that tree.

This means that if a tree contains multiple errors, each error must be fixed individually and validation performed again until all errors have been solved.

In this case, the log file reports that the ItemsTreeDef node (the first node in the action tree) contains an XML tag for Mailboxes where ELOxc expects Groups.

Return to the ELOxc Console, select the root node of the action tree, and click XML. It shows the following:

As shown in the figure, there is no Groups tag at all in the XML definition for that node. Check the ELOxc Technical Reference for what the node type requires.

In the case of the ItemsTreeDef node, no settings need to be entered to the Groups tag. However, the tag needs to exist. Enter <Groups /> between the <Restriction> and <Mailboxes> tags.

Click Save to save the changed XML, then click Validate again.

This time, no errors are detected. Close the validation window and return to the instance overview page. Click Publish Changes to save the current instance configuration as the active one. Click Stop to stop the instance if it is running, then click Start to start the instance.

Let the instance run for a few minutes. After the instance has run a few times, the tree shown above does not appear to be working correctly. The defined path is not constructed in ELO and no messages are filed to the repository.

Navigate in a file browser to the instance log directory. You now see that a ZIP file is created each time the instance runs, containing log files each time. Open the log files in this directory and look for issues:

• Were all required mailboxes/groups detected?
• Do the log files contain errors?
• Look through the _Worker_ log file. Does the tree perform actions in the desired order? Are there any warnings?

In the action tree shown above, there is one warning in ELOxc_[timestamp]_Worker_00.log:

This means that an action was performed on an Exchange item that was not actually saved to the Exchange store. In this example, the Match & Replace action in the tree changed the subject line of the message, but the change was discarded without being written to Exchange.

This means that you need to add a Commit action to the tree after the Match & Replace action. However, the log file shows another problem that was not detected as an error:

The path has been constructed for the messages in the repository. The messages have been exported successfully from Exchange, but nothing shows up in ELO.

After looking through the log again, you notice that there is no instruction in the action tree that messages themselves should be saved to the repository. Add an Archive action after the Export action, then a Commit action to the end of the tree.

Click Validate to check the tree definition. If successful, return to the instance overview and publish and restart the instance.

Let the instance run and see what happens this time.

This time, the messages are stored in the repository. However, something strange happens after the instance has run through a few times:

Each time the instance runs, the subject marker [ELO] is added on to the start of the subject line of the messages. This does not show up in ELO, but it does appear in the original messages in Outlook.

The problem in this case is that the ItemsTreeDef node in the action tree has been set to Archived e-mails = Ignore. Once the setting is changed to No, the tree runs as intended.

However, this error affects much more than the subject line of affected messages. The error in the tree definition causes all messages to be processed again every time the instance runs - rather than once when the messages are stored to ELO. This can massively impact server performance. Use the various mailbox, entry point, folder, and other filter possibilities to reduce unnecessary repeated item processing to a minimum.

Summary

After creating an action tree in ELOxc EWS, make it active by (1) validating the action tree, (2) publishing the changes to the instance, and (3) restarting the instance.

To ensure a tree works as intended, make sure that the log files do not contain any errors or (unintended) warning messages. The ELOxc applications in detail chapter contains a list of log files associated with ELOxc EWS and what each log file contains.

However, in addition to the log files, check the effects of ELOxc in both ELO and on the Exchange items it processes.

Information: It can be useful to install the GotoId ELO Java Client script to help troubleshoot action trees and other configuration issues. The GotoId script is available on the ELO SupportWeb at: http://install.myelo.net.