Moving File – Keep the Process Running at Target Library

One of the AgilePoint Integration for SharePoint features is that, the process is cancelled once the document is moved to target library.

In some cases, the users may want to keep the process running even the document is moved to another library. The solution for this is to associate the same process template at the target library.

Where Can I find the error logs?

Knowing the locations of log files comes very useful when you are facing issue and trying to troubleshoot.

AgilePoint Server:

[VirtualServerDirectory]\AgilePointServer\log, e.g. C:\BPMWebSite\AgilePointServer\log

 

SharePoint Integration v2:

1. Check the log file location at the AgilePoint Configuration List in your SharePoint site.

1. AgileConnector logs: [VirtualServerDirectory]\AgilePointServer\log\AgileConnector, e.g. C:\BPMWebSite\AgilePointServer\log\AgileConnector
2. In some extreme cases, some errors will be logged at the Event Viewer.

SharePoint General Error

If you see a general error message at SharePoint, e.g. 'Unknown Error' with a 'Go back to site' link, see pictures below, you can see the full error thrown by SharePoint by modifying a few entries in the web.config of SharePoint web application, i.e. the stack trace, the debug mode and the custom error mode. Search and set following values. It will let you know exactly what failed. Remember to backup your web.config before any changes.

For SharePoint 2010, you need to modify this in two web.config files, i.e. the web.config of SharePoint web application root (e.g. C:\inetpub\wwwroot\wss\VirtualDirectories\12345YourPortNumber), and also the web.config under the layout folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS).

Do this:

1. Set CallStack="true"
2. Set debug="true"
3. Set customErrors mode="Off"

For example:

<SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">

<customErrors mode="Off" />

<compilation batch="false" debug="true">

 

General error page from SharePoint:

Synchronous and Asynchronous AgilePart

In the constructor of AgilePart descriptor, the Synchronous property is set to true by default. This makes the AgilePart operates in synchronous basis, i.e. the process waits until the execution of the AgilePart finished before it promotes to the next activity. Also because of the AgilePart is running under a synchronous mode, the process is considered ‘active’ and the object remains in the memory, not being swap out for better server performance.

public class MyAgilePartDescriptor : WFAgilePartDescriptor
{
public MyAgilePartDescriptor()
{
base.Synchronous = true;
}
}


If your server always have high load, you may utilize the asynchronous capability of AgilePart. To implement this, just set the Synchronous property to false. The process still waits for the AgilePart to complete before promoting to the next activity, but the memory of the process instance object is swapped out from the memory, and hence releasing the resource for other server processing needs. Besides the asynchronous behavior, any other thing of an asynchronous AgilePart is the same as synchronous AgilePart, i.e. the way to debug an AgilePart, the logging behavior, credential used to run the AgilePart, deployment of the AgilePart, etc.

Implementing Asynchronous AgilePart

Here is an example:- an asynchronous AgilePart calls an external web service (or any external service) for some data processing. The action for the data processing might take a few weeks. In this case, the resource for the process instance shall be swapped out from the memory of AgilePoint server for better performance.

i. In AgilePart code, set the Synchronous property to false (This is set to true by defalt).
public class MyAgilePartDescriptor : WFAgilePartDescriptor
{
public MyAgilePartDescriptor()
{
base.Synchronous = false;
}
}
ii. Pass the automatic work item ID when calling external service.
public void Method1(
WFProcessInstance pi,
WFAutomaticWorkItem w,
IWFAPI api,
NameValue[] parameters)
{
try
{
CallExternalService(w.WorkItemID);

if (w.Synchronous) MarkSuccess(api, pi, w, parameters);
}
catch (Exception ex)
{
HandleException(api, pi, w, parameters, ex);
}
}

iii. Once the AgilePart activity is exited, the status of the Automatic work item is set to “Waiting”. The process does not promote to the next activity.
iv. The external service that works with the asynchronous AgilePart shall call the CompleteProcedure function passing in the automatic work item ID (see example below) to notify AgilePoint server that the processing is completed, and AgilePoint Server set the status of this Automatic Work Item to “Completed” and promote the process instance to the next activity.

public void CallExternalService(string autoWorkItemID)
{
//....some processing codes here


IWFWorkflowService api = GetWorkflowService(); // refer tohttp://kb.ascentn.com/KB/KnowledgebaseArticle10020.aspx for details on getting workflow service object
api.CompleteProcedure(autoWorkItemID);

return;
}