Skip to main content

Hi there,

I'm working on a feature that needs to show within a Smartform, will save a record in SQL, which then the Workflow will pickup later to use.

 

The issue is that once both Smartform and Workflow are deployed, the Smartform will start behaving like the new version immediately after deployment but there will be some instances where the WF process would still be the pre-deployment version. This is an issue.

 

The way I would like to tackle this is to have some form of feature switch on loading of the Smartform to either show the feature or not. The best way to do this is to compare the workflow version it is opening with a configuration so "if workflow version is THIS or higher, show it", but I can't find workflow version in the Open Worklist Item.

 

Is there an easy way to get the version at runtime (even server side so as not to show any SMO call to the client)?

Under the Workflow Reports => Workflow Analytics category there is a SmartObject called Workflow Instance Report.



 



This has a method called Get Process Instance Detail - you could pass to this the name of the WF to the inputs to reduce the data returned form the server, you can then add a filter to specify the process instance - that will get you the version.



 



Or a way that doesn't need the K2 apis -  you can make a note of the last currently executing process instance that is on the old version and store that somewhere after you deploy.



 



Then you could parse the id from the serial number (presuming you have an instance running at the time you use the form) and then if it is greater than that value use the new functionality, otherwise don't.



 



Cheers

Looking into the WF reports SMOs wouldn't be a bad idea at all, if I could narrow down the return even more via the inputs.

An alternative I was thinking is kind of like a hybrid between your last suggestion and what I'm trying to achieve; getting the WF start date from the Open Worklist Item instead of version and using that to compare to.

It's not a 1:1 replacement to version since we'd need to manage the configured timestamp to base the logic on in the event that a rollback of the workflow version is required.

Adding the Status of Active will massively reduce the list of returned results, any input parameter provided filters the results on the server so it shouldn't place too big a load on the server.



 



Cheers

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings