Start and Stop Batch scripts for SPS 2010 Developer Workstation

 

Overview

There is enough resources to setting up your Windows 7 Developer workstation for running SPS 2010. On an occasion we may not always run the SharePoint 2010 and the SQL Server on our Win 7 workstation or our lap tops all the time. Here I have been using Batch scripts to on demand Start and Stop quickly SPS 2010 and SQL Server services.

Place the below script in a batch file and run as administrator to start or stop your  SharePoint and SQL Services. Not the order  or start and stop matters so pay attention.

Make sure you set each of the services to start manually in your Services console so that its the script that controls the service activation.

Below in both the scripts make sure to substitute for your <YourSQLServerInstance> name.

Start Script

net start <YourSQLServerInstance>
net start sptracev4
net start spadminv4
net start w3svc
net start iisadmin
net start sptimerv4
net start SPUserCodeV4
net start SPSearch4
net start OSearch14

Stop Script

net stop W3SVC
net stop IISADMIN
net stop SPSearch4
net stop OSearch14
net stop SPTimerV4
net stop SPUserCodeV4
net stop spadminv4
net stop sptracev4
net stop <YourSQLServerInstance>

 

Happy Sharepointing….

Implementing Multiple Documents Approval Workflow in SharePoint 2007

 

Overview

OOTB SharePoint 2007 has support for running workflows at an Item level but not as applying workflow at group of items. This will be supported in SharePoint 2010 with Documents Set.

recently I had opportunity to design and implement one such workflow where approvals for multiple documents was required. Below I am sharing thoughts and approach to the architecture and design approach and various design element.

Workflow Architecture

• Below is the high level architecture of the Multiple Documents Approval Workflow implementation.
• I have discussed the logical architecture implementation approach.
• First lets review some of the common necessary workflow components.

Necessary Workflow Components

1. Generally complex document workflows may need to support  both serial and parallel approvals.
2. Front end screen should support end user to interact with the workflow components.
3. Behind the End User Screen, there will be SharePoint lists and libraries assets.
4. These lists and library assets will facilitate capturing following data:
1. The Workflow Metadata-Forms Library
2. The Workflow Tasks- Tasks List
3. The Workflow History- Custom List
4. The Approval documents- Document library.
5. The custom workflow will be deployed to the Custom Workflow Library.
6. End user will interact with the workflow with Submission and Approval forms.

Key Design Concepts for the Workflow that would facilitate multiple documents approval.

1. The key to the design is that a Workflow running on the Custom list will allow to capture the Business Specific metadata.
2. The workflow running at this custom list will operate at the each approval item level.
3. The workflow process should allow both Serial and Parallel Approval.
4. The Workflow forms should allow for the End Users to upload multiple approval documents at each workflow level.
5. This multiple document upload should then trigger a sequence of events by the workflow.
6. These should be to generate a new unique workflow number for the workflow event.
7. Then create a sub folder under the "Approval documents Library" with folder name as Approval  Workflow Number.
8. Then upload all the user documents to this sub folder, check in the documents with minor version 0.1.
9. Further for each approver review, each documents should be presented to the end user with document version and check in/check out status.
10. For each document the reviewer should be able to check out and update and check in back the document with the check in comments.
11. The checked in comments will be stored at the document library level.
12. Each approval workflow level Approval/Revise/Reject comments will be maintained at the workflow level.
13. After each check in check out a minor version should be incremented.
14. If you have phases in the workflow say after each major phase a Major version to be incremented.
15. After each user submission, necessary confirmation and next step notification emails will be generated for appropriate workflow participant.

 

1. Process Flow
1. Originator starts by clicking on the "Submit New for Approval" button from the "Workflow Management" section.
2. System should confirm user intention to actually initiate a new workflow. (Yes/No)
3. System to initiate a new workflow process (1).
4. System to generate a new Workflow Number (2)
   1. Sequential number or some code form such as code for Your Workflow  YW-2010-000001, YW-2010-000002, needs to be determined at implementation time.
5. System to create a new folder by the name of Workflow number.
6. System to present end user with Submission form. (3)
7. End user to enter workflow approval data and upload multiple approval documents. (4)
8. Each uploaded documents will be actually uploaded under the above created subfolder by the workflow number under the Approval Documents library.
9. End user to submit the workflow. (5)
10. System to capture workflow meta data and update the Approval Workflow custom list. (2)
11. System to generate appropriate notification emails.
12. System to create new task for the next approver.
13. Next approver to either open the received notification email, and click on a email link to respond to the pending task, or from the Workflow Management screen, look up the pending task from the "My Tasks" and click on the link to open the task.
14. System to present Approver with new Approval Form (6)
15. Approver could open any approval documents and review.
16. If the approver wants to edit the document then approver must first check out the document, make their edit, save the document and check the document back in. (7)
17. Workflow to advance further for each workflow defined steps and process the remaining steps.
18. Upon workflow completion, the state for the documents need to be determined at the implementation time based on weather the workflow was approved or rejected.

End User Views

1. My Tasks
   1. This view to list all the active tasks for the current user.
   2. End user should be able to act on the pending task by clicking on the task.
   3. This list is sortable/filterable

1. Specific list of columns and the default view will be determined at the implementation.

1. Active Workflows
   1. This view to present list of all the active approval workflows
   2. This list is sortable/filterable

1. Specific list of columns and the default view will be determined at the implementation.

1. Approval Documents
   1. This view to present end user with all the approval documents that belong to the active Approval Workflows.
   2. End user could directly open the documents for review purpose.
   3. End user could directly check out, open the documents for edit purpose.
   4. End user could directly check in, the documents with the per document review comments.
   5. This list is sortable/filterable

1. Specific list of columns will be determined at the implementation.

1. Workflow Management
   1. This control to present end user with button to initiate a new workflow
   2. This control to also present end user with workflow search controls.
   3. Search results will be displayed on a separate search page.

1. Completed Workflows
1. This view to present end user with all the approved documents .
2. These documents are only for read only.
3. End user will not be able to edit/delete or make any changes.
4. This list is sortable/filterable

1. Specific list of columns will be determined at the implementation.

Implementation Options

1. Workflow Technology options
   1. Out of the Box SharePoint Workflows
      1. Approval
      2. Feedback
      3. Signature Collection
      4. Disposition

1. SharePoint Designer Workflows
   1. Wizard Driven Designer.
   2. Very good Conditional flow builder.
   3. Limited auto forms generator.
   4. Deploy to a single list/library.

1. VS.NET developed custom workflow
   1. Custom Coded workflow process.
   2. Custom workflow provides broader opportunities for workflow logic and future capabilities implementation.
   3. No UI Support (use either ASP.NET or InfoPath form).
   4. Can be deployed to any server any site any list.

1. Forms Options
   1. ASP.NET
      1. Custom ASP.NET pages can be developed to provide Forms functionality.
      2. These custom ASP.NET pages will need to be a SharePoint master page inherited pages and should follow SharePoint development standard.
      3. Will be complex to develop.

1. InfoPath Forms and SharePoint Forms server
   1. Custom InfoPath Forms can be developed to provide adequate End user Forms experience.
   2. InfoPath forms technology is meant for this Forms functionality.
   3. To add to the InfoPath strong feature, SharePoint brings in the Forms server technology.
   4. The Forms server is capable of delivering the InfoPath forms via the browse interface, meaning end user do not need InfoPath rich client to interact with Forms.
   5. InfoPath provides rapid development experience.
   6. The minimal configuration of the Forms Services provides excellent mechanism for delivering the Forms to the end user browser in a workflow process.

1. Landing Page Web Parts
   1. For each of the Workflow Management page views, Out of the box web parts can be utilized and customized.
      1. My Tasks
         1. This will be a filtered List view web part on the Workflow Tasks list.
         2. This Web part will be filtered for current user by connecting to a Current User Filter Web part
      1. Active Workflows
         1. This will be a filtered List view web part on the Workflow Tasks list.
         2. List View will be filtered for where status is not "Completed".
      1. Approval Documents
         1. This will be a filtered List view web part on the Approal Documents library.
         2. List View will be filtered for where the documents are Approved.
      1. Workflow Management
         1. This will be a Content Editor Web Part with custom HTML code.
         2. The HTML code will facilitate the end user confirmation via the JavaScript and further upon confirmation, initiation of the workflow.
      1. Approved Documents
         1. This will be a filtered List view web part on the Approval Workflow custom list.
         1. List View will be filtered for where status is "Completed".

1. Document Management
   1. SharePoint provides Document management functions Out of the Box
      1. Check in Check out
      2. Versioning (Minor, Major)
      3. Document Approval

1. Detailed Implementation Options and Comparisons
   1. Out of the Box SharePoint Workflows
      1. Design
         1. Simply Configure each workflow for a given list/library.

1. UI
   1. OOTB submission and approval pages

1. Deployment
   1. SharePoint Feature Driven, simply activate appropriate workflow features. By default all workflows are activated.

1. Extensibility
   1. Not available

1. End User Experience
   1. Relevant for the limited functionality

1. SharePoint Designer 2007 designed workflows
   1. Design
      1. Declarative Workflow Design experience through wizard
      2. Simple Initiation form auto generation for submitter.
      3. Simple Task form auto generation for approver.
      4. All SharePoint designer workflows are flow chart type and do not support State type machine workflows.
      5. Wizard Driven Experience

 

1. Deployment
1. SPD workflows are always deployed to a single list/library.
2. There is no packing and deployment option.
3. There is coding involved.
4. All the auto generated workflow definition files are deployed to SharePoint hidden library
5. However there are hacks to pick these files and re design or make use of these files in VS.net as new workflow (but that is out of scope for this discussion)
2. Extensibility
1. Use SPD to open the site "Live" and open the workflow.
2. Modification could potentially break the active workflow instances.
3. End User Experience
1. Submitter to see the above initiator screen, but there is no way to provision the document attachments or reference other related documents.
2. With alternative approaches, at the least we could accommodate a free text field where the submitter lists all the approval related documents. Or a document library with each new folder with workflow number where the documents are uploaded.
3. More disconnected experience
4. Version Management
1. SharePoint will maintain all the workflow deployed versions.

1. VS.NET developed custom workflow
1. Workflow Development
   1. Customizable with design canvas with predefined controls.
1. Provides great depth of freedom to implement business logic.
2. Could implement support for Multiple Documents approval
3. Can implement both flowchart type workflows with Parallel and Serial workflows and a state machine based workflows.
4. Complex to implement
5. Time consuming to develop
6. No integrated UI development
7. But can integrate with InfoPath or ASP.net separately (Covered below
2. UI choices
1. InfoPath
1. Design using InfoPath Office Application, rapid development.
2. Deploy with Browser enablement. Easier to enable.
3. Rich end user experience
4. Simple integration with VS.net workflow
5. Complex to perform data integration with VS.net workflow (Time consuming)
2. ASP. Net
1. Alternative option.
2. More time to develop than InfoPath
3. Would choose if there was no Forms server and was only WSS (Comes with MOSS Enterprise license)
3. Deployment
   1. Entire workflow components can be packaged as a SharePoint Solution Framework.
   2. Can be deployed as intuitive SharePoint Feature
   3. Solution feature can be controlled by administrator
   4. Workflow can be developed and tested and deployed to each different servers
4. Extensibility
1. Custom tasks types can be developed to implement special or non OOTB functionalities (reference to multiple documents)
2. But it will be a complex task.
3. Workflow solution can be further updated and the Features can be further deployed by carefully evaluating the impact of deployment and retention of active workflow instances.
5. End User Experience
   1. More intuitive and richer experience due to advanced Forms entry, data presentation and submission experience.
   2. Easier workflow interaction with custom build Web part components.
   3. Advanced and more interactive reporting experience.

Design Constraints

1. Out of the Box Workflows
1. Comparison with OOTB workflows and requirements
2. Each OOTB workflow is one leg of our requirements
3. We cannot bind them one by one serially to achieve our designed flow
4. Not being able to update multiple documents.
5. SharePoint workflows are single document-centric processes
6. From a document library, you can choose document and then choose to kick of a workflow

1. No dynamic task assignment.
1. No task assignment based on availability.
2. Cannot check for Out Of Office from Exchange Serve
2. SharePoint Designer 2007 Workflows
1. The auto generated simple forms do not support any onscreen validation or conditional data input.
2. Every input is independent field.
3. Data validation logic cannot be enforced.
4. Only data
5. Multiple Document reference and document management functionality cannot be implemented. (may be very complex to implement)
3. Approval Document management has to be handled separately from the workflow process and directly from the Approval Documents library.
   1. Workflow process and the document review process managed directly from the library would go independently.
   2. This to provide more disconnected end experience.
4. SPD Workflows lack deployment functionality to more than one location.
1. One developed and deployed against a single list/library under say development server, we cannot take out just workflow process and deploy against a Production server.
2. There are other alternative approaches to mitigate this issue.
1. Once developed clean up the development test data.
2. Back up the site collection.
3. Deploy restore the site collection in production.
4. But this can happen only one time.
5. Thus modifications cannot be easily developed under development environment and deployed to production.
6. Only production workflow has to be directly modified for any future updates risking loosing /inadvertently affecting production data.
7. There are other hacking options, but would not recommend as there are chances of loosing/affect the production system.

Capacity planning

• Other items that needs to be addressed are the capacity planning and include your growth plan.
• Consider how many average documents per workflow.
• Give attention towards the know SharePoint guidance for over 2000 items per view.

Implementation Decisions

Then work through your Implementation decision strategy such as to implement which specific feature using possible technology options. You can prioritize each of these requirements. This should further help you to decide which option makes more sense on the larger scale.

Requirements Prioritization

Priority: High/Medium/Low

*Design Impact: In the order of function availability to low cost simple design to advanced end user experience with high cost of development. Any selection of choices selects corresponding type of technology choice across. Choices are among (OOTB, SPD, VS.net Custom Workflow)

Let the Business/Client/End user decide on the prioritization.

Hope this helps….

Email links to InfoPath tries to open the form in Rich InfoPath Client as supposed to Browser based form.

 

Overview

For Nintex Approval Task, you will have emails text. Under the email you would add a link to respond to the task such that the link would open the InfoPath Form over the browser.

Issue

Email link to open the form, tries to opens the InfoPath form with rich client as supposed to Browser.

Diagnosis

I have noticed some flakiness with the link in the task email where the reference to “{Common:ItemUrl}” embed the link.

I have noticed in one of our build, clicking on the link tried to download the InfoPath file and open with the Rich InfoPath Client as supposed to open in browser. Below is the link.. and next to it is the HTML snippet of the email..

.xml">.xml">https://webmail.MyCompany.com/owa/redir.aspx?C=9255f52eea184a3ab087aadad9d7b0da&URL=http://<FileUrl>.xml

Email HTML

<P style="MARGIN: 0in; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Click&nbsp;&nbsp;</FONT><property style="COLOR: blue; TEXT-DECORATION: underline" title=Hyperlink contentEditable=false refText="here" link="true" refLink="{Common:ItemUrl}">here</property>&nbsp;&nbsp;to review and respond to the task</P>

Below is the Working link:

.xml">.xml">https://webmail.MyCompany.com/owa/redir.aspx?C=9255f52eea184a3ab087aadad9d7b0da&URL=http://<FileUrl>.xml%26OpenIn%3dbrowser

HTML

<P style="MARGIN: 0in; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Click&nbsp;&nbsp;</FONT><property style="COLOR: blue; TEXT-DECORATION: underline" title=Hyperlink contentEditable=false refText="here" link="true" refLink="{Common:ItemUrl}">here</property>&nbsp;&nbsp;to review and respond to the task</P>

As you can see I had highlighted in the working link the addition of “&OpenIn=Browser” is present at the end of the link. While you will also notice that the HTML snippet is the same.

Well its simple setting that is causing this issue. If you look over the Forms libraries Advanced Settings, you will see that Browser-enabled Documents is set to use the client application.

Simply switch this over to Display as Web Page.

Now any email notifications that get generated after this setting will add the “OpenIn=Browser” query parameter to the link url.

Implementing workflows using MOSS 2007, Nintex Workflow 2007 and InfoPath Forms 2007

Overview

Lately I been busy building workflows using the Nintex Workflows 2007 on MOSS 2007 with InfoPath 2007 forms over Forms server. I have gone through my own share of learning and building some nice integrations. I have also come across several issues as they exist, some have answers some don’t. In the next several days I will be blogging on each of several of my thoughts over design, implementation and runtime related topics as below.  I will enable links as I get chance to post on each of these topics.

Topics

• Design
  • Implementing Multiple Documents Approval Workflow
  • Integrating SharePoint, Nintex and InfoPath
• Nintex
  • Best Practices for Nintex
  • Limitation of Nintex
  • What do I like about Nintex?
  • Integrating Nintex with InfoPath
  • Thinks that you will need to watch out while in Nintex Workflow Development.
  • Custom My Workflows web part for Nintex
  • Custom My Workflow Tasks web part for Nintex
  • Links in Nintex Workflow
  • Generating Custom Workflow ID
  • Updating InfoPath data from Nintex
  • Extracting File attachments from InfoPath submissions
  • Implementing Item security for other assets lists/libraries
  • Email links to InfoPath tries to open the form in Rich InfoPath Client as supposed to Browser based form.
• InfoPath
  • How to exceed InfoPath 5 expression barrier from Rules?
  • How to show InfoPath data for debugging with a trick?
  • How to improve Custom People picker speed?
  • Custom InfoPath footer with version/build information.
  • The quirks in InfoPath over Forms Server.
  • What not to do?
• SharePoint
  • Workflow timer frequency
  • Save conflict issue
  • How to secure Forms library
  • How to Assets List/Library
• Implementation
  • Deploying InfoPath Forms
  • Deploying Nintex Workflows
• Development
  • My Build Process
  • My Build Scripts
  • How to debug?

If you are interested in any of these topics please leave comment and I will blog on them.