The recommended system requirements for Process Director are as follows:

Process Director server

• Microsoft Windows 2012 R2 Server and above (all service packs are supported)
• Microsoft SQL Server 2008R2 or higher, Oracle 11g or higher
• .NET Framework 4.5
• Intel Xeon 2Ghz (or higher) CPU, minimum 2GB memory, minimum of 1GB free hard drive space

Process Director eForm Builder

• .NET Framework 4.5
• Microsoft Word 2007 or higher (32-bit)

User / clients

• No client software or plug-ins required
• Process Director can be accessed by any client browser – all browsers are supported, including mobile devices

Process Director will run on most standard server level hardware. However, it is impossible to provide specific confirmation in an FAQ section. A basic eForms server will run well on a Intel dual-core, 2GHz server with 4GB of RAM (8GB if hosting SQL Server) and mirrored hard drives. However, a server accessed by 50 users or more and utilising the workflow engine would require a minimum of 8GB of RAM and a dual core Xeon processor and SAS hard drives, for example.

The server stores the forms and processes and is responsible for rendering them for clients and running the script and processes behind them. Consequently, it is important to pay careful consideration to RAM, processor performance and hard drive speed.

It is also possible to increase performance, simplify management and help locate and resolve performance bottlenecks by splitting the components of Process Director across multiple servers. The two main components (processing / web server and database server) can be installed on separate servers.

We recommend separating the process and web components from the database if you operate larger systems with multiple users or performance is important.

A clean installation of Windows 2003 Server will typically use less than the first 512MB of RAM for normal operation. This means that whatever is left can be used by database server and the Process Director server. On a dedicated server, a total of 2GB (512MB for Windows, 1GB for SQL and 512MB for Process Director) should be adequate for a simple installation.

If other applications are running, it is important to have more memory. If you have multiple system users or utilise complex processes, additional memory will be needed.

Multiple databases on one “instance” of SQL Server share memory but SQL can also have several isolated installations on the same server called “instances”. Some applications such as the McAfee ePolicy Orchestrator virus scanner management tool or Symantecs’ BackupExec install their own instance of SQL to store information and statistics – both require their own memory in addition to the Process Director instance!

SQL server will automatically use available memory. If you have more than 2GB of RAM in your server and SQL is using up all available memory, it doesn’t necessarily mean that expanding your memory will result in a performance increase.

Although the requirements suggest up to 1GB of hard drive space is needed, a full Process Director installation will utilise less than 512MB. The additional space is required for storing the online form templates and the data retrieved from online form submission.

As storage is cost effective and it is rare to see a hard drive smaller than 120GB, the space is rarely the issue but careful consideration should be given to hard drives as they contain moving parts and often create bottlenecks in performance.

It is essential to have some form of fault tolerance on your servers hard drive configuration. For more information please see our server storage FAQ.

As the hard drive will be a limiting factor on your server’s performance, we recommend you review the latest SAS drives.

With the right operating system, web and SQL server version, full 64bit processor support is possible with Process Director. This will increase the amount of RAM the system can utilise – it does not effect speed.

The speed of the processor will have an effect on performance but any server class processor is suitable for simple systems. More complex installations will require multiple core processors such as Intel Xeon. Please note: additional licensing costs may be applicable for Process Director to utilise additional core processors.

We recommend Windows 2008 R2 Server for Process Director.

Any edition including Standard or Advanced will work as will 32bit and 64bit versions. We recommend you install the latest updates from the Windows Update website.

Although Process Director can be installed on the free SQL Server Express Edition for small systems or testing, we recommend the full version of SQL Server 2005 or 2008 (Workgroup, Standard or Enterprise) for larger systems.

This version will increase the number of clients supported and provide hassle-free backup, mirroring and system maintenance.

Many processes within a workflow system are initiated by a user action, often a completed form being submitted. However, there are occasions where a process needs to be initiated from another application or system. Ideally the other system could use a web service call to start the process or possibly a simple URL to perform an HTTP POST with the relevant data.

Often though, the other application may not support any of these methods or perhaps the requirement is to fit into an existing process with no amendments. In such scenarios, we have implemented systems that initiate or add data to a process via a SQL trigger.

SQL Triggers

Microsoft SQL Server is able to support triggers on both a new record INSERT and an existing record UPDATE query. In the SQL query code example below, simply insert the workflow GUID in to the relevant space and when a new record is created in tblMyTable it will launch the workflow.

Example SQL To Create Trigger

USE [Database]
SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON
GO
CREATE TRIGGER [dbo].[trgMyTable]
ON [dbo].[tblMyTable]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
DECLARE
@vPointer INT,
@vResponseText VARCHAR (8000),
@vStatus INT,
@vStatusText VARCHAR (200)
EXEC sp_OACreate ‘MSXML2.ServerXMLHTTP’, @vPointer OUTPUT
EXEC sp_OAMethod @vPointer, ‘open’, NULL, {Line Wraps…}
{…} ‘GET’, ‘http://{Server Name}/WD/Services/wsWorkflow.asmx/Run?WFID={Process GUID}‘,TRUE
EXEC sp_OAMethod @vPointer, ‘send’
EXEC sp_OAMethod @vPointer, ‘responseText’
EXEC sp_OAMethod @vPointer, ‘Status’, @vStatus OUTPUT
EXEC sp_OAMethod @vPointer, ‘StatusText’, @vStatusText OUTPUT
EXEC sp_OADestroy @vPointer
SELECT @vStatus, @vStatusText, @vResponseText
END

This can enable integration with applications where not otherwise be possible. However, you should consider the effect on database performance.SQL triggers are run synchronously. Therefore, the INSERT or UPDATE statement will wait for the trigger while all possible steps are run within Process Director.

Assuming the form has a field called Number, which contains the phone number to dial, it is possible to simply add a button to the form (or even call this from the eForm display event) to call a REST web service. The syntax of the call is below:

http://3CXServer:5000/ivr/PbxAPI.aspx?func=make_call&from=10&pin=10&to={FORM:Number}

When clicked the button initiates the call and returns a status (in this case simply confirming the call has been dialled) which can be displayed in another field on the form if needed. The operator simply needs to lift their handset or if a headset is used the call is connected immediately.