Deploying InfoPath/SmartObject/K2 Workflow/SP2010 solutions across multiple environments

  • 29 August 2011
  • 8 replies
  • 2 views
S
Badge +3

We currently have a ticket raised for this, but just wanted to get a general idea on how the greater public handle deployments across multiple environments.


We currently have: 3 separate Development Environments; System Integration; User Acceptance; and Production environments.


We are also running development using the Agile Methodologies, with deployment cycles every 2-3 weeks.


This means we need to package and deploy solutions from our various development environments (through MSBuild Scripts) to System Integration; UAT; and then Production quite often.


Our solutions follow a simple pattern: InfoPath Forms with SmartObjects integrated to allow all form data to be stored in SQL Server; SharePoint Content Types to handle the Forms within a Form Library; and K2 Processes that are launched from within the Form.


When deploying our solutions, we are:



  2. Changing our environment in the object browser to point to the new Environment;
  3. Refreshing the InfoPath Form to change the connection strings to point to the new Environment;
  4. Rebuilding the project;
  5. Creating a deployment package from VS 2010 to generate a MSBuild script;
  6. Running a batch file that runs the MSBuild script to deploy to the environment.

Unfortunately, this doesn't remap the SmartObject connection files in the InfoPath Forms properly, and there are some connection strings that continue to point to the development environment.  It seems we are still having to: Publish the Form as Source File; run through the XML and XSF files to remap to the correct environment; Publish the XSF back over the top of the XSN file prior to deployment. 


This process is long and tedious.  We have a number of SmartObjects in each form, and a number of processes that we deploy.  We are having to do this for each environment install, and then back again to get development up and running properly as well.


Is anyone else experiencing this headache, and if so, what are you doing as a work-around as this isn't really an option for us.  We are potentially looking at removing SmartObject Integration from the Form itself and just handle it from the Workflow, but we are quite deep into our development and such a change in design would cost us dearly (missing our deadlines).

8 replies

C
Badge +10

I would also love to hear how people are deploying accross environments and what challenges they face.  This has always been an interesting topic for me even without K2 in the mix.  Would love to hear more.

R
Badge +2

It sounds odd that you would have to edit the infopath xml to modify the smartobject connections. Blackpearl is designed to help prevent the need for that. 


 


Is there any possibility that you have three environments defined but that the underlying environment variables have been duplicated so they are effectively the same? Other than that have you used the service synchronizer and or the smart object tester tool to synchronies the service instances and smart object relationships across environments? If so, all you should need to do is,


 


1 change the target environment


2 rebuild the msbuild package


3 deploy the msbuild package


 


because the smartobject GUIDs are sync'd across environments everything should work.


If you would like more information on the environment configuration


http://help.k2.com/en/EnvironmentLibrary_Whitepaper.aspx “The K2 Blackpearl Environment Library.pdf” Whitepaper


(I’m still looking for he service instance / SO synchronization documentation..)


Good Luck!

T
Badge +10

I typically do the deployment directly from K2 Studio across the different enviornments since security hasn't been an issue that would require that I run the MSBuild scripts. When deploying to a new enivronment  I would change the K2 environment to the enviornment I'm publishing to, refresh the infoPath form SmartObject connections and then deploy. 


What tricked me initially is the issue where the SmartObject server connections aren't updated in the InfoPath form at the project level but I found out that those connections only get updated during the actual deployment inside the InfoPath form that's published into the form library. The InfoPath form inside the process will still have the original SmartObject server specified if you look at the extracted xsn, but the ones deployed to the SharePoint envirionment would work correctly. 


Perhaps MSBuild isn't making the changes to the IP form like K2 Studio does during deployment.

S
Badge +3

That's exactly right Tim, when deploying through Visual Studio or K2 Studio the mechanism to change the InfoPath Forms Connections are different from deploying (or rather creating a deployment package) through MSBuild.


The "Create Deployment Package" does not go through the same process, which means that the InfoPath Forms aren't being modified to accept the new connection strings mapped in the Envrionment Variables within the msbuild file.


I've logged this with K2 Support and they've said they'll get back to me with a solution to this - in the meantime I was just wanting to see if anyone had a workable solution.


For the environment I'm working in, if it doesn't come with a packaged deployment it won't get deployed (unless there's a specific reason - but having a bug in the deployment mechanism isn't going to get me far). 


Refreshing  the InfoPath Forms is inconsistent in remapping the connection files.  Essentially with the "Create Deployment Package" option, whatever the connections are in the XSN file (to see these you either need to rename the file as .cab or Publish to Source Files) is what will be deployed to the target environment.  So if some of your connections haven't "refreshed" it will hold the previous target and cause issues at runtime.


If you have 10 SmartObjects the connections will be determined within both the .XML files and the .XSF file.  All these need to point to the correct target environment or they'll break at some point in the running of the workflow.  Even manually manipulating these files though can lead to trouble because if you miss one (and I have 6 forms with over 10 SmartObjects per form) you won't know until your run them, which can get quite stressful and become quite time consuming.


Hope this clears some of the confusion. 

S
Badge +3

The SmartObject/Service Broker connections are fine.  It's the integration between the InfoPath Form and the internal connection files contained within them that are causing the issue.  If you extract the connection objects from the InfoPath Forms, you'll see a bunch of XSD and XML files as well as the Manifest.xsf file.


Each of these files contains the schema and connection strings to the environment you wish the SmartObjects to point to.  When using Visual Studio to deploy, it will call a self-contained method that will remap those files to match the target environment variables associated with it; however, if you just create the deployment package without going through the deployment, so that you can manually deploy, it does not go through this same method.


It's at this point that the issue occurs, because now your InfoPath Form contains mappings to other environments (in my case I have 3 developers each working on separate machines, so their Forms have mappings to their environments); when I change my target environment, refresh the InfoPath Form through the Integration Wizard in the hope that it will change all those internal mappings to point to the new target environment, it only partially does it.


So now I'm left with 6 InfoPath Forms from 3 different development environments that part of the connection files (.xsf, .xml, .xsd files) held within the 6 InfoPath forms are pointing to the correct target environment, and the other connection files are pointing to their original development environment.  I call this: XML hell. 


I hope that reads ok, it's sometimes hard to explain.  K2 Support have looked through the solution I've created and have suggested that I modfiy the XML manually by hand as a work-around until they can assist with a solution.  I'm just hoping that someone out there has come across this already and has a nicer or simpler way of doing it as so far this is quite a lengthy process (especially considering I need to go from Dev to SI to UAT to Production environments - it'll take me a month of Sundays).


I appreciate the reply, hope this makes more sense.

D
Badge +11

I have not encountered your situation.  I don’t have to change the InfoPath form when moving from one environment to another, and I don’t change the connection strings in the template. I use deployment packages for moving solutions between environments.  When the environment libraries are setup correctly you can take the same msbuild package and use it in all environments without rebuilding or changing any files.


Check to make sure all of the environment library fields are correct for each environment.  If you have multiple developers and they are not connecting to the same server for environment settings then they must make sure their fields for all environments are correct as well.  When deploying to an environment, make sure you are using the right environment switch on the msbuild command.


The SmartObject connections in the form are only used at design time; at run time the connections are pulled from a data connection library.  The deployment process uses a data connection library called “K2 blackpearl Data Connections” to store the data connections in UDCX files so they are external to the form.  The values in your environment library for the target environment are put in the UDCXs, so if they aren’t right, the values in the UDCX aren’t right.


 

S
Badge +3

G'Day David, thank you for your response. 


With your MSBuild package, would you be able to walk me through how you are able to do this?  Do you deploy from Visual Studio to your development environment first, and get the package from output of that deployment to deploy to other environments?


When you deploy, do you do it on the target environment, or from a development machine?  We currently do not deploy from the target environment.  We have a deployment box for this. 


If my environment variables were incorrect, then removing the SmartObject from the InfoPath Integration Wizard and re-adding them after switching the Object Browser settings to point to the new environment, wouldn't work at all.  It seems that without doing this, the InfoPath Client Task fails - trying to connect to the development environment.  It launches correctly kicking off the workflow, but from there on, I get troubles.


I do the deployment of the SmartObjects using the MSBuild command, and have no troubles with this.  The deployment of the workflow I do the exact same way.  So I'm confident that this is correct. 


I'll try a deployment to the development environment, get the output, run the msbuild command with a switch to another environment (mapped in the MSBuild file) and see what becomes of it.


We've been given a PoC deployment package from K2 Support that I will also be testing that uses the API that Visual Studio calls to package the InfoPath Form and ensure that it accepts the right environment variables.  From what I've been told, when you just right-click create deploy package from Visual Studio it doesn't run through the same process.  So that makes it a different process and a different output package.


Appreciate your feedback, and very keen to hear how and from where you run the deployments as what you explained is what I'm after.  Get the same deployment output and with simply changing the MSBuild switch, have the ability to deploy to any of the environments defined within the MSBuild file without recompiling or modifying the InfoPath Form in any way. 

S
Badge +3

Issues experienced in this project were due to multiple developers (x3), each with their own single development VM with: SP2010; SQL Server; VS 2010 with TFS 2010; K2 BlackPearl.


All developers were working on one solution which included 6 K2 Processes with 6 InfoPath Forms associated - 1 for each Process.  Each development VM was named differently (VM_1; VM_2; VM_3).  This meant that the K2 Environment Variable for Development was different for each.


When getting latest from TFS into the VS 2010 environment, the mappings for the InfoPath Forms were not picking up the new environment - just the environment that they were created in.  So if the InfoPath Form was created on VM_1, and the developer on VM_2 got latest from TFS, all the InfoPath mappings would store VM_1 on it. 


If deployments occurred from VM_2, it was causing mapping issues with InfoPath Forms integration.  When deploying to the System Integration environment of VM_SI, from VM_2 using the "Create a Deployment Package" option, and using the MSBuild scripts, the deployment would fail half way through as it would try to connect to VM_1 during the deployment.


In future, we will start setting up with on K2 Development VM and have multiple Client Development Machines that share that environment.  This way, when getting latest from TFS, the environment is always correct.  After restricting the development environment to just VM_1 we were not receiving this issue anymore.


 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings