WorkFlow Monitor
Last updated
Was this helpful?
XMPro WorkFlow
Last updated
Was this helpful?
When accessing the ‘History’ tab in the WorkFlow Monitor UI (The XMMonitorUI Web App is installed alongside the XMMonitor service), if the history does not display and you notice the URL in the browser address bar contains the text “aspxerrorpath=/XMMonitorUI/History.aspx”, it means that an error has occurred in loading the job history.
In order to see the full error message, you will need to turn off custom errors in the web.config file. Set mode=Off in the customErrors element:
You should then see a more detailed (Yellow Screen Off Death) error message. If the error you are receiving is, The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element., it means the size of the history records is larger than the default allowed transfer size of the XMMonitor API.
To resolve this you need to increase the maximum allowed message size in the web.config file by adding the maxReceivedMessageSize attribute to the binding element and setting its value to an appropriate value. The example below increases the size to 256KB (from the 64KB default).
When installing XMAlertService to run under a domain user account, the account must have the right to logon as a service in the XMPro server.
This logon can be granted in the Local Security Policy using the following steps:
Logon to the computer with administrative privileges.
Open the ‘Administrative Tools’ and open the ‘Local Security Policy’.
Expand ‘Local Policy’ and click on ‘User Rights Assignment’.
On the right pane, right-click ‘Log on as a service’ and select properties.
Click on the ‘Add User or Group…’ button to add the new user.
In the ‘Select Users or Groups’ dialogue, find the user you wish to enter and click ‘OK’.
Click ‘OK‘ in the ‘Log on as a service Properties’ to save changes.
Ensure that the user which you have added above is not listed in the ‘Deny log on as a service’ policy in the Local Security Policy.
When creating create the Jobs in BAM it keeps on showing a message “callback request failed due to internal error” then it reverts back to the login screen.
This error relates to the configuration of Actions or Triggers and can be due to:
Multiple Actions were configured that use the same dll. The same assembly was uploaded every time in the field below shown in yellow.
Multiple Actions were configured that use the same dll. The same assembly was uploaded once and not again for the subsequent actions.
To resolve the issue, you will need to:
Step 1:
Navigate to the C:\Program Files (x86)\XMProPty Ltd\XMMonitor\Actions and/or C:\Program Files (x86)\XMPro PtyLtd\XMMonitor\Triggers folder. There should only be one instance of the dll you uploaded. If for example you configured 3 actions, and for each you attached the dll, you will see the following:
Delete all the dll’s not needed. In the example above delete the v2.0 and v3.0 dll’s.
Step 2:
Open the SQL Server Management Studio and navigate to the XMMonitor database. It will normally be installed as CompanyName_XMMonitor. Open the Action table. You will see one of the following:
If the dll was attached for each of the actions, you will see the following:
If the dll was attached once and not for the other actions, you will see the following:
The resolution in both cases is the same. Ensure that the value specified in the DLLFileName field is the same for All Actions and is the same as found in the Actions folder. The result should look like this:
Step 3: Restart the XMMonitor service
Step 4: Continue to configure the Jobs.
It has been reported that the task / activity link in reminder emails is not working.
The email link was something like “http://localhost/XMPro/…. “.
From the email context, the localhost is the server from where the email is accessed and the following 404 page not found error.
Modified the Site URL for XMPro XMAlert Service using XMPro XMManagement Console to point to the server URL instead of local host and saved the configuration.
Restart the XMAlert Service. The link in the reminder emails is working as expected.
To use the file monitor function of XMAutomate requires three areas of setup.
The first being the XML/CSV source file, a sample follows:
Note: When using XML a root node is REQUIRED.
The second is the activity that will be triggered:
Note: The file attachment object is required to load the original document (can be access through the process as required).
The third being the XMAutomate configuration setting:
The file prefix can be used to separate different XMAutomate activities depending on the requirements (Can be left blank).
Note: The groupnode being used in reference to the source XML file. RepeatingNode is used when populating an object group using a common node in the XML.
Our project has been configured so that XMAutomate will monitor a folder path and initiate a process if there is a new file in the folder.
This is working fine until today until a few configuration changes were made in the process and then deployed the process again.
From then onwards, XMAutomate is not invoking the process (or) processing the files.
An attempt to debug and see why XMAutomate is not able to invoke the process even when there are files to be processed.
Where are the error log files or what is the issue?
In event viewer, custom views ..> Administrative Events, the error log for the XMAutomate was found.
The script in the Process is having an extra ‘}’ as a result the files are not picked and processed by XMAutomate.
The script was modified and everything is working as expected now.
Another item to check when the automated scripts are not behaving is to try and submit the activity manually.
If you cannot submit the activity manually, then the automated services will not be able to.
Users are getting a 404 error when clicking the link in the notification e-mail.
The link looks as follows:
(The [siteurl] has been blanked out for the above)
The templates have a [LINK] placeholder which is correctly set.
The problem is because the myActionItem has been renamed to ActionItem and the URL is being redirected incorrectly.
To resolve, create a new file in the website folder called myActionItem.aspx and add the following code into it:
Added a debug option to help identify when emails are not being generated where the issue is being generated from.
Stop the service
Close the MMC console
Copy the two files into the installed service directory (C:\Program Files\eXomin\XMAlert Service\[Service Name])
Open the XMAlert.Service.exe.config in a text editor and add the following:
The enable should be set to false in production and set to true when a debug is required When set to true the debugLocation is used to store the file it generates. This can be any location on the machine
Close the text editor
Copy the file XMAlert.Configuration.dll to C:\Program Files\eXomin\XMManagement Console\ and override
Open the MMC console and restart the service
The reason for the text editor adding and enabling/disabling is so that the option is not accidently switched on via the MMC console.
It is a debug option and should only be used as required and then disabled. Please ensure that when you enable the logging to disable it, otherwise the file is going to grow and performance and space starts becoming an issue. Please contact your implementation partner for details on the above.
