Original article is posted here.
Buried in this process are way too many static values.
Don’t judge my sprawling process. I was still finding my sea legs.
When I first started developing Workflows, especially processes that integrated with other systems (SQL in particular), I would occasionally run into this:
“Hi Andrew, we need to move the SQL server you’ve integrated with. Here’s the new connection info. Hope it’s not a big deal. You declared your connection string variable up front, right?”
Oops. Well, dozens of components buried in layers of embedded models later, I had updated all the SQL components. Except this time, I used a project property. The next time the SQL connection string needed to change, I updated a single value, published, and enjoyed the success.
Variable Sources
In this article, let’s talk about several different sources for reusable variables.
Initialize Data Component
Using the Initialize Data component is akin to a declaration block at the top of a piece of code or script. One of these components should be used at the front of a project/model, and can be reused to clear data or set specific values for variables at any point in a project. Variables in this component are each configurable by data type and whether the variable is an array or a single value.
As a loose rule, it is a good idea to add any variable you’re going to use in your project to an Initialize Data component up front. Exceptions to this loose rule can be made arbitrarily as needed, with considerations being made for errors that can occur when null values are evaluated by some components.
Variables declared in an Initialize Data component only persist inside the model in which it is located. These variables can be mapped into and out from additional models with additional configuration effort.
Note that one Initialize Data component can replace one hundred Add New Data Element components. It’s the same idea, you can just add as many variables as you want, instead of one-at-a-timing the latter.
Project Properties
In each Workflow project, at the top level (the item in the “Project” panel on the left that is named for the project, just above the “Model: Primary”), there is a number of tabs with project data contained in each. On the “Properties” tab, single-value text/string variables may be defined. These variables will be available inside any model or embedded canvas in that project. This is a good place to house variables like SQL connection strings or authentication values. Project properties can be found at the top of the variable tree under “[Project Properties]”.
In the project directory, the Project Properties can be found and directly edited in the “properties.config” file. Note that if a property is configured as a “Password” field, it is encrypted in the config file and reads like this:
<ApplicationProperty>
<PropertyName>ADDomainAdminPassword</PropertyName>
<PropertyValue>mdcJ1iH3adiakJkJaoo6tCSXzp5IzNR6SY6gZwP3oKFnTG7vdihm7R+pAgXMxVNc</PropertyValue>
<EncryptInXml>true</EncryptInXml>
Project Properties are read-only within a project and cannot be traditionally altered by the Workflow process.
Profile/Application Properties
In the Process Manager portal, you are able to define Application Properties. These variables are helpful for projects which may move between environments. For example, let’s say I built a project in which a SQL component runs against a SQL database in that environment. What if I need to publish that project regularly to another environment (test to development)? I can have environment-specific variables set in each Process Manager portal and the Workflow project will grab from the same area regardless of the environment.
Application properties may be array variables; however, the data type scope is limited.
Enable the Application Properties in the same section (different tab) as the Project Properties above.
Once enabled, Application Properties will be available when you browse variables in your project.
Global Data
The phrase “Global Variables” is often accompanied by a bit of stigma. If you use too many, your variables cloud becomes polluted and frustrating to navigate. For best practice purposes, always try to restrict and contain your process variables where possible, whether within modular containers (embedded or linked models, etc), or by using resource variables instead of Project Properties and Global Data.
That being said, there are some instances where Global Data is a handy fit. For example, if you want a non-global variable to persist across linked or embedded models, input and output mappings must be created for each model. Global Data will persist in any model in your project, and the value can be replaced as well (read/write).
Global data is found at the top of the variable tree.
SQL (External) Data
One way to ensure that data will always exist independently of any Workflow processes is to write the data to a database during and/or before process runtime. Using an external database, we can save and then later retrieve variables for use in our projects. However, this means that we need to also have a container for the connection string to that database. This method is good for lots of data that needs to be saved for a while yet.
More reading:
http://www.symantec.com/docs/HOWTO98568