The K2 Pirate

Hello!

I want to tell you about an underused tool in the K2 Blackmarket community arsenal: The Process Instance Version Migrator.

This tool allows you to make inflight migrations of process instances between process versions.

It uses an API called LIM - Live Instance Management.  This API /is/ a K2 Supported API however the tool itself is community supported.

Credits for this tool go to Neil Maartens – A K2 Consultant now working in the US.  K2 Underground username: NeilM

So – on with the tool.  Download it from here: http://www.k2underground.com/groups/process_version_migration_utility/default.aspx

Extract the tool – full source code is included however you'll want to navigate to the folder: ProcessInstanceVersionMigrator\ProcessInstanceVersionMigrator\bin\Debug

Here you'll find a .exe which is to run the program and a .config thatcontains the server connection strings.

FIRST MODIFY THE .config

You'll need to modify the following:

<add key="K2SqlConnString" value="Data Source=localhost;Initial Catalog=k2server;Integrated Security=True;MultipleActiveResultSets=True"/>
<add key="K2ServerName" value="localhost"/>
<add key="K2ServerPort" value="5555"/>

By default the tool will work best if you're running on the (a) K2 Server as the K2 Server Service account.

Next run the tool .exe

Use of the tool should be quite straight forward.  When it runs you are presented with a window that describes 7 steps – each with a button associated.

Step 1 – Check the config file!

Step 2 – Click "Get list of processes" – this populates a drop down list with the process types on the specified server, select the process type you with you migrate.

Step 3 – Click on "Get Active Instances" – this will fill the table with a list of running instances of the selected process type, including the status and version of the instances.

Step 4 – Select each instance you wish to migrate – processes in error state can be migrated also.

Step 5 – Click on "Get process versions" – this will load a list of versions for the selected process type – then select which verson you wish to migrate the above instances to.

Step 6 – Click on "Get process version activites" – this loads a list of activites in the selected version that you can then select.  The tool will then perform a goto to the selected activity after migration. You can also choose not to redirect at all, or redirect to the current activity if you want to rexecute the current step (useful if the instance is in error and you want to restarted from the failed point).

Step 7 – Perform the migration!  This is the final step and the act can not be un-done.  By now you should have thoroughly tested the migration scenario in you test environments.

The table will show Migrating, followed by Migrated for each selected process instance.

Good luck!

P.S: Some other things to know.

• There are only certain things you can chance and expect migration to work
  • See product documentation: Designers > K2 Designer for Visual Studio > Live Instance Management > LIM – Sourcecode.Workflow.Management > Important Notes
• I have tested this tool myself on version from late 0807 (release of API) to 4.5 1320 (Latest at time or writing)
• You can migrated backwards or forwards
• <todo… suggestions welcome>

Cheers,

The K2 Pirate

A common requirement in reports is to display the AD display name of a user rather than their username.  Ashley Evans, rather than DOMAIN\ashley for example.

There are of course a few ways to do it, but sometimes you just need to get the display name in the report and not worry about the rest of it.

This is where the attached code comes in to play.  It's a .net assembly that simply resolves a username to a display name, what's special about it is that it's strongly named, and includes the required code access security configuration to allow it to be used from within Reporting Services.

You can use it as it is, or just as an example of how to call custom code from SSRS.

There's one static method that takes a username in one of the following formats, and returns the display name.  If it fails for any reason it simply returns the input data allowing at least something sensible to be displayed in the report.  It's also multi-domain aware.

Input formats:

• SecurityLabel:DOMAIN\Username (e.g. K2:DOMAIN\Username)
• SecurityLabel:Username
• DOMAIN\Username
• Username

To use it you'll need to GAC the assembly in the attached project and deploy the CAS configuration to both the rssvrpolicy.config and/or rspreviewpolicy.config files.  The former allows the assembly permission to be loaded from SSRS for running the reports and the latter is for previewing the reports in Visual Studio 2008.

The default locations of the config files are:

C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\rspreviewpolicy.config
C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\rssvrpolicy.config

The required CAS configuration for the policy config files is in the attached project in a file called: report server.config

It should be placed just above the final two closing </CodeGroup> tags.

To use the code.  Add a reference in your Visual Studio report project as follows:

Then in the field where you want to do the lookup, configure an expression similar to this:

=SSRSADInterop.ADLookup.UserDisplayName(Fields!Originator.Value)

Hey presto.  It works.

If you get errors, check the CAS configuration – it can be a bit fiddly to get working.  Ok, that's an understatement – it took me bloody ages the first time!

Have fun,

Hoshy, the K2 Pirate

Code: SSRSADUserLookup v1.0