Skip to main content

I'd like to have something that allows me to pull a named default value that is environment specific. For instance "DoctorsADGroupName" would return a specific string (or number or date value) that's specific to the SQL server it's pulling from.

 

In the past I've created a table in SQL to do this, so I could see creating a stored procedure and SmartObject where I give it a name and get a value back. In K2, is this what the string table is for? Are there practical or physical limits on using this? I like the idea of a specific table for this purpose where I can add as many values as I like.

 

If a smartobject is the way to go, is there a way to directly populate a datalabel on a form or would I need to include a view which references the DefaultValues SmO?

Hi Nigel

 

It sounds like Environment Library fields will do what you are after.  The environment libraries and string tables can be a bit confusing.

 

On your development environment you should have a library for each of your environments (e.g. Dev / Test / Prod). You can create your own fields (generally use the "Miscellaneous" type) by adding a new Template field. This will add the field into each of your libraries. You can then give it the value you want for each environment by changing it in the respective library.

 

When you deploy a package from Dev to one of your other environments, the new field will get created in the target environment with the value you specified in the library on Dev. If the package contains a process, or you are deploying a process directly from VS or K2 Studio, then a copy of the environment library (for the target environment) will be created in a "String Table" on the target server. There can be more than one string table for each K2 environment. The string table is only used by processes - you can see which one is being used by expanding the process in the workspace.

 

So, in your example you could create a new template Miscellaneous field "DoctorsADGroupName" in Dev, and then in each library give it the value required for the respective environment (e.g. DevGroup for Dev, TestGroup for Test, and ProdGroup for Prod). When you deploy a form to test that uses this field, it will get created in the environment libraries in Test, and populated with the Test library value on Dev ("TestGroup"). If you deploy a process the field will get created into a string table (name of table will be dependent on how you deploy) again with the Test library value on Dev.

 

To make things confusing, your Test and Prod environments will usually have multiple environment libraries (e.g. Dev and Prod). What you need to be aware of is that each environment uses the "Dev" library when getting the value for a field at runtime (for forms). So in Test and Prod you can ignore the values in the other libraries (i.e. other than Dev) - except if you plan to deploy from these environments.

 

Check out this White Paper for more info: http://help.k2.com/environmentlibrary_whitepaper.aspx#

 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings