In production environment, we have a SharePoint site with some Nintex 2007 workflows. Now we need to replicate the production site for testing purposes.
The target server already had Nintex installed when I restored the SharePoint backup.
Unfortunately, it turned out Nintex license has expired on it so we're a little paralyzed.
The workflows seem to have been moved with the backup, however some workflow steps in Nintex designer show exclamation marks with this tooltip:
queryListActivity1 of type Nintex.Workflow.Activities.QueryListActivity is unrecognized by Nintex Workflow
When I activate Nintex license, how can I ensure that Nintex workflow is deployed correctly? I see the following options:
copy Nintex database to the new server and try hook it up with Nintex instance (how?);
save existing workflows on source server using Nintex Export feature and upload them on target server.
What is the best one, or are there any other options available?
The preferred method is to export your workflow from the Developer License site and then import the workflow in your newly licensed site.
Once you have imported the workflow, simply save and publish.
Be aware that copying workflows between sites doesn't always result in a working result.
For example if your workflow queries a list, the connection to the list is implicitly based on the List unique ID (GUID) on the development server. When you move the workflow to the production server the equivalent list will have a different GUID.
You will often have to open these steps in the editor and re-create the list query (pointing at the right list) to get them to run.
I would be very keen to find a tool that can migrate Nintex workflows and automatically fix up things like site URLs and list GUIDs myself.
Related
I'm looking at upgrading my current TFS instance and planning to copy and restore databases as per Microsofts Advanced Upgrade which means I am pretty much installing the new product from scratch and restoring the databases then running a migration tool.
I see in the installation notes that you can integrate SharePoint with it as an optional extra. Why would I do this? Is the idea to store project documentation in a SharePoint Document library per project and be able to link to that content rather than as an attachment to the Backlog Items and Bugs in TFS?
I'm having trouble finding any documentation of team workflows with SharePoint and TFS and I suspect that its because no one really does it.
More importantly would SharePoint integration impede future product upgrades or moving to Visual Studio Online?
In my eyes, SharePoint as a TFS portal has become much less desirable due to the improvements in Team Web Access (eg Charting) but it still has some uses.
With the integration enabled, you will see a Documents tab in Team Explorer which will take you to the dedicated SharePoint Portal (created when you create the TFS Team Project) where all your documentation can be stored. Of course without SharePoint integration you can still happily link Work Items to documents in SharePoint, you just don't have a dedicated portal created for you.
If you are using one of the MSF process templates then some useful documents are created for you on SharePoint when you create the Team Project (xlsx reports etc). However, if you are using the much better VS Scrum template then no documents are created even if you have SharePoint integration enabled.
If you are using the Enterprise edition of SharePoint then you get some good dashboards (bugs, code quality etc.) and you can also publish your custom excel reports easily. This functionality requires Excel Services and so is not available in the standard edition (there are some dashboards created but they aren't that useful).
Share information using the project portal
https://msdn.microsoft.com/en-us/library/ms242883.aspx
Your team can use the SharePoint portal to share information in the following ways:
Share data contained in reports or dashboards
Share team progress using predefined or customized dashboards.
Share documents, files, images.
Share team knowledge and processes using the SharePoint wiki.
Reference process guidance for select team project artifacts.
If you want to add a portal to an existing project:
Configure or add a project portal
https://msdn.microsoft.com/en-us/library/ms242865.aspx
I am newbie to Sharepoint.
I want to create workflow as template using Sharepoint designer and deploy it as feature.
Following link Workflow Deployment Using Features suggests, this can be achieved in visual studio.
I have following questions
1. Can sharepoint foundation has workflow as template
2. Can we deploy workflow made in designer as feature
If answer to both these is yes, please share some links to get started for these.
You can use Reusable workflow for this.
Assuming you are on SharePoint 2010,
Create a new reusable workflow.
Save it and publish it and test that it works fine
In the ribbon, use Save as Template option to save it.
It will get saved in Site Assets Library as wsp form where you can download it and upload to other sites as wsp and activate the feature to use it there.
More information can be found here:
http://msdn.microsoft.com/en-us/library/ee231580.aspx
I know that we can reverse engineers sites definitions and other sharepoint moss entities but can we take a workflow that has been created via the UI and reverse engineer it to a vs.net based workflow?
Yes.
Each of the OOTB workflows in MOSS are acctually what you call "vs.net based workflows".
IE - the OOTB workflows are provisioned via features, which you can find the manifests for in 12Hive/Templates/Features.
Find the feature.xml for the workflow you want to reverse engineer and it will point you to the dll. You can use Reflector to then see inside the assembly.
On top of the VS workflow, all the OOTB workflows add .aspx initiation forms to the workflow. These forms collect the parameters (IE approver's email) that get passed into the workflow.
This should get you pretty far down your path.
Whats the best way to deploy a webpart in WSS3 or MOSS2007 which has a database dependency? Should the .wsp include code to create the database, should I encapsulate the .wsp in another installer which handles the database creation, or should I supply two different packages to allow the admin to handle the backend creation?
Well, I prefer the SharePoint way where you create the databases from a SharePoint admin page in Central Administration. Just take a look at how SharePoint handles the creation of new Web Applications where you are asked to name the database server and the name for the SharePoint content database.
In other words, I would opt for a WSP only deployment. The WSP should include a database configuration page (an ASPX page) plus a farm level feature for installing a custom action link to the page inside Central Administration. The beauty of doing it from Central Admin is that it runs in a context with privileges to create new databases on the SQL server. Hence, you do not need to ask the user for login and password to the database server.
The configuration page should upon successful creation of the database persist the connection info in the SharePoint configuration page, using a custom derivative of the SPPersistedObject class. Web Parts can in turn read these settings to connect to the database.
MSI installers should in my opinion be avoided when designing SharePoint apps.
What sort of client is your webpart aimed at?
I imagine it might be worth being slightly flexible in your approach and considering multiple methods of installing your webpart.
So for someone without a dedicated DBA it might be best to have one .wsp.
(Although this should be robust enough to handle superuser's installing it.)
Alternatively go for a .wsp and a msi (or even scripts), which will give the installer
more control over exactly how it is installed.
(I'd prefer this approach, over the .wsp only approach.)
With MOSS 2007 (the question is probably applicable to WSS as well but I'm working in MOSS at the moment) is it possible to have the same Workflow on every Pages list within the site collection?
We're deploying a site with a basic 2-stage approver workflow so I'm not developing a custom one, just using the existing Approver workflow but having 2 approval groups working sequientially (see this blog post: http://www.sharepointblogs.com/tommysegoro/archive/2008/08/18/configuring-sharepoint-moss-2007-multi-stage-approval-workflows.aspx).
The problem is that when you create a Publishing Site it gets (by default) a single approver workflow, not the one I want.
Can I have the workflow enforced across the site collection and for any child site collections? Or do I need to create my own site template (and can that even define the workflow as it's deployed?)?
Edit
Just to clarify, I'm wanting to have the ability to create a new MOSS publishing site which has some slight modifications to the standard Approver workflow which is out of the box within SharePoint. I'm not wanting to deploy a different workflow, just modify the existing.
When you create a Publishing Site you get a "Parallel Approver" workflow which assigns workflow tasks to a group called Approvers and is set to run the workflow tasks in parallel. I need to change the groups (add a new one) and set it to be sequential.
You can create a feature which will add the second work flow to the Pages library when activated using the SPFeatureReceiver class, and staple that feature to the existing Publishing Site site definition using feature stapling.
Here are MSDN posts on using feature event receivers and feature stapling:
http://msdn.microsoft.com/en-us/library/bb862634.aspx
http://msdn.microsoft.com/en-us/library/bb861862.aspx