This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.
In K2 blackpearl SP1 when a process is deployed it auto generates process SmartObjects. That is if the "Create Workflow Reporting SmartObjects" or "Create Workflow SmartObjects" checkbox on the SmartObject Association screen is checked. On deployment of the process, if these SmartObjects already exist, blackpearl saves the GUIDs for the SmartObjects and if not it creates new GUIDs. If associations are made to other SmartObjects through the process it creates an association entry for the link between these two GUIDs. When the deployment packages that create the process and the SmartObjects are relocated to another environment and deployed within the new environment, the following error will occur: [Figure 1. Error Description]
Reason for the error
The process SmartObjects are created with GUIDs and therefore the links between the process SmartObjects and the associated SmartObject are broken.
The K2 developer is deploying a K2 Solution using the deployment package to a new environment on machines with the following items installed:
- Microsoft .NET Framework 2.0 SP1
- K2 blackpearl SP1
The error can be resolved by upgrading to K2 blackpearl 0803 (4.8075.1.0). In K2 blackpearl 0803, the kprx is updated to keep track of the GUIDs being used. When the deployment package is then executed on another environment it will use the same GUIDs thereby preserving the link between associated SmartObjects.
By adding this functionality, it was necessary to cater for cases where there was existing process SmartObjects with the same name on the server but different GUIDs to what is held in the kprx. So it can happen that when deploying to a server where there are already process SmartObjects with the same names on the server but different GUIDs the following error will be presented: [Figure 2. Error Description for SmartObjects with the Same Name on the Server but Different GUIDS]
This occurs because for different reasons. One example is:
- A process was deployed and then an activity/event was deleted and recreated with the same name. This will create new GUIDs for the activity/event SmartObject and the above error will occur on deployment.
To continue the user has two options:
- Go to the SmartObject Association Property Wizard for the process, click on the Synchronize button, choose the current environment and click the OK button. The deployment should now succeed.
[Figure 3. Synchronize Functionality in the SmartObject Association Wizard]
- Or, alternatively, the user can uncheck the "Ensure SmartObject GUID integrity" checkbox on the SmartObject Association screen and deploy. The check to see if the GUIDs differ will be ignored during deployment and SmartObjects with new GUIDs will be created if they don't exist or the GUID from the Server will be used if it exists. Basically, this option works similarly to the way it used to work prior to K2 blackpearl 0803.
[Figure 4. Uncheck Option on the SmartObject Association Screen]
|Note: This might result in SmartObject associations being broken if there are associations to other SmartObjects in the process.|
Web workflow uses the second option automatically since it regenerates the process on every deployment and therefore cannot deploy without this option being unchecked in the background. However, nothing stops the user from obtaining the kprx from the server for the Web Workflow process and clicking the “Synchronize” button in K2 for Visual Studio.
For processes built prior to K2 blackpearl 0803, K2 will attempt to automatically synchronize the GUIDs on a build or deployment using the default SmartObject server from the Environment. The user will get a warning to indicate that it was synchronized and that the new GUIDs must be saved. If the automatic synchronization failed (for example the user was offline or the SmartObject server was offline), the mapping for the process will be created as if it was a new process. If the process is then deployed, the user might receive deployment errors as described above indicating that the process needs to be synchronized. This ensures the least amount of effort for the majority of users upgrading from K2 blackpearl SP1 to K2 blackpearl 0803.