|Posted: 2014-06-04 10:22|
Quite often we're asked for assistance with copying a process from one database to another. This is a common request for new customers who wish to move a process from a test database to their live database. The steps required to carry this out are detailed below.
Identify existing process to be copied
To begin with, identify the process you want to copy across so that the script it uses can be found and copied across to your other database. To do this navigate to the process you want to copy by going to Start > Configuration > Automation > Processes > Select the Process.
To get a copy of the script click on the script icon (shown above) > Copy the content of the 'source code' field and navigate to the database you want to set the process up in.
Next, parameters for the script need to be setup. A parameter is a variable defined within the user interface, which the script will use. This allows the script to use different values without having to modify the script itself. At this stage we are simply saying what the parameters are and not assigning a value to them (this will be done at a later stage).
To do this go back to the script in your existing database > Select the 'Parameters' tab and view the full set of parameters (if there aren't any you can skip this step). If there are parameters, in your new database navigate to the parameters tab and create a matching parameter for each of the existing ones. Once you've done this, save and close the Script.
NOTE: It is important that the names of these are exactly the same for the script to correctly process them.
Setting up the new Process
Once you've copied the script across to your new database with any parameters, you can now create the Process. If you are unsure the difference between a script and a process, take a look here.
Next the parameter values for the process need to be set. This is done on the Process and not the script itself because it's possible that one script might be used for several processes and have different parameter values.
Quite often the parameter values can be copied across from one database to another, but there are some parameter values which are likely to be different on each database. It is recommended that for the following types of parameter values you check the value on the new database:
Once you've done this 'Save' the process to ensure the parameter values you've entered aren't lost.
All processes run in the name of whichever User 'owns' it, therefore each process must have an Owner. Clicking on the padlock will show the current Owner of the process and the access permissions:
In order for the process to run, the Owner must be an enabled User with a valid Workbooks licence. We recommend that separate 'API Integration' user is created and used so that any actions/changes the process makes are clear to see from an Audit point of view (they'll appear as being made by 'API Integration').
If you don't wish to allocate a licence to an 'API Integration' user, please make sure the user the process is running as has full system admin rights and is exempt from password expiry. Failure to exempt the user from password expiry will result in the process falling over when the user is due to change their password, as like the user its password will be invalid.
One of the most common causes of process failure is due to Ownership. If you think your process has failed because of an issue with the Owner then please take a look at the section on Process Ownership found here.
Notification of process failure
On the main tab of the process, under the 'Other Settings' section, you can set which User is notified when the process fails and becomes disabled (we would advise that this is set to one of your Support Contacts so they can raise a Support Case if required. Bear in mind the potential impact of that user being on holiday or even leaving the organisation). If the process does fail for any reason, this User will receive an email notification that the script has failed and has been automatically disabled.