How to Handle Environment Variables with Nintex Workflow

A topic you sure will run across is how to handle environment variables when you deploy workflows designed with Nintex Workflow. The values are by definition just valid for one specific environment, and have to be changed in order to deploy the workflow into another environment. Example for environment variables are URLs of web services or service accounts, which are different between development, test and production system.

Basically, there are three ways how you can handle this information:

  1. store the information within the workflow activity
  2. create a workflow variable
  3. create a workflow constant
Most people start with alternative 1. The environment specific information is directly configured on the workflow activities. This has one advantage: You are pretty fast when you configure the activities the first time. But in the long run the disadvantages outweigh. After deploying the workflow from environment to the next stage, you have to update all affected activities. Beside the fact that this is time-killing, it is also error-prone. Furthermore, such a workflow requires some effort if you put it under source control. For every functional change you implement, you have to update all workflow variants (e.g. for development, test, production).

Alternative 1: Configuration values are set in the workflow activity. 


With alternative 2 you will set the workflow variables carrying the environment specific information to the beginning of the workflow. So you do not have to scan the complete workflow for activities that require an update. Consequently, the risk of a faulty configuration is also mitigated. But you still have the issue, that you have a workflow variant for each environment which has to be maintained in the source code management system. And this method cannot be applied to credentials for service accounts.

Alternative 2: Configuration value is set in the beginning of the workflow.


The issue that you have to maintain a variant for every environment is resolved with alternative 3. In this solution you create a workflow constant for every environment information your workflow requires. Therefore the workflow does not have to be altered when you deploy it into another environment.

Alternative 3: Configuration values are set with workflow constants.


How workflow constants can be created using a script will be featured in my next post.

Comments

  1. Anonymous30 May, 2012 23:51

    Hi,

    I have defined project manager by creating a workflow variable. The workflow starts and the variable is filled with one id. some time later IT changes the login id/display name of that project manager due to this the workflow terminates with an error. "An error has occured". It cannot find that person. I

    Is there any way to change the approver id from old to new for a running workflow?

    Can I change the workflow variable value in the middle of a running workflow?

    Thanks

    Regards,

    Siskin

    ReplyDelete
    Replies
    1. sfsfsf31 May, 2012 21:43

      Hi Siskin,

      in general the workflow should fill the variable as late as possible. The best would be just before the activity where it is required. This should mitigate the issue.

      If you need the information from the variable in multiple activities than you should fill it from another data source every time you need it. This can be done with a workflow constant or by saving the information in a SharePoint list. If you change the information stored in one of those, the workflow can use the most current information when it needs it.

      There is no way to update the value of a workflow variable from outside the workflow. The workflow has to pull the information himself.

      Please let me know if this answers your questions.

      Delete

Post a Comment

Popular posts from this blog

How long does "Delay for..." really wait?

Image
First looking at the action "Pause for..." I was thinking think that I could configure the delay period precisely to the minute. However, when I used this activity I discovered that the activity did not behave as I as expected. This was especially true when I entered an interval shorter than five minutes. I always waited longer than configured. Looking deeper, I found out that the cause for this is the SPTimerJob job-workflow  which controls the triggers for " Pause for... ". This timer job runs with the standard configuration every five minutes. If you set " Pause for... " to a shorter interval, the trigger send by the timer job will be sent every five minutes anyway. The same applies when you set the action to pause the workflow for any period of time that lies between the configured schedule for job-workflow . Of course, an option to solve this issue is to reconfigure the timer job to run in shorter intervals. But ask yourself if this is really nece
Read more

Run Now in Nintex Workflow 2010

Image
With version 2.3 Nintex introduced Run Now into Nintex Workflow 2010. Nintex promises that with Run Now the integration with other system will be easier, because workflow designers can test actions with Run Now support already during the design stage. It is not necessary to start and step through the workflow until you reach the actions. Can it keep up to the promise? Run Now can be accesed on all supported actions during the workflow design stage. Start with a new blank workflow and then drag an integration action into the design area. I will be using Query LDAP for the rest of this post. The other actions work alike. After you have configured the action select "Run Now" in the ribbon. A new window is displayed where you can test the configuration. If you are using workflow variables for the configuration you can replace them with actual values. And remember: As soon as you press execute the target system will behave as if you execute the action from the workfl
Read more