Babak Mahmoudi’s Blog

Localization for Persian Language…

Archive for the ‘SharePoint’ Category

State Machine Workflows

leave a comment »

I often find the differences between State Machine and Sequential workflows much like those of event-driven programming with old control flows. Back to old days when we programmed with FORTRAN, we often thought of how to control the flow of program by branch instructions to do a job. The flow of control often had only one or at most a few of predefined paths. We could plan for these paths with the IF THEN branching instructions. Event driven programs are not so. Who can imagine the paths of instructions when someone uses Word?

State Machines are type of event-driven workflows most suitable for situations when it is hard to draw all of possible paths of a process. This is why State Machines provide a more flexible approach in programming Business Processes. It’s a pit SharePoint focuses on Sequential workflows.

Written by Babak Mahmoudi

July 24, 2011 at 7:26 am

Posted in SharePoint

Localization of MOSS Built-In Workflows

with one comment

MOSS comes with a number of built-in workflows, such as Approval, Collect Signature and Feedback. It seems that standard language template packs, like that of Arabic language does not support these workflows. The challenge of localizing these workflows is actually that of translating the associated InfoPath forms. In this post I’ll discuss it in detail.

 Research and Findings:

XSN files are actually CAB files, one may open and edit and then recab them.

 Generic workflows, like Translation Management are implemented in Microsoft.Office.Workflow.Pages They have a code behind page to IniWrkflIP.ASPX with an onload method that actually computes the form and requests it from form server. The localization occurs here where a $Subst:LCID in the form urn name will be replaced with the actual LCID.

internal static
string GetLocalizedFormUrn (string
formUrn,
SPWeb
web)

{
     return formUrn.Replace(“$Subst:LCID;”, web.Language.ToString(CultureInfo.InvariantCulture));
}
Problem with “the form is not workflow enabled”
I did everything I could for preparing a Persian version off the forms. But when I installed these forms, I still had problem. SharePoint reported a “the form is not workflow enabled” error. Actually the form templates on Centeral Administration has a Workflow column which indicated “No” for my forms. Now I know that my forms should be installed with the feature to get enabled. So I did reinstalled the workflow feature. It just seems that any form in the feature directory will get installed this way.
We don’t know how’s that the original form templates are not “PUBLISHED” the way we should “publish” our forms to a sharepoint site prior to installing them on the form server. When we publish our forms the form will be marked for being published on our servers and we don’t know how they will be published on client urls:

The XSN has a tag with PublishURL on it, u omit this and form sever will assume that the form is correctly published.
<xsf:xDocumentClass solutionVersion=”12.0.0.6″ productVersion=”12.0.0″ solutionFormatVersion=”2.0.0.0″ name=”urn:schemas-microsoft-com:office:infopath:ReviewRouting-Assoc-1065-Edit:-myXSD” publishUrl=”C:\MyProjects\FarsiMOSS\GenericWorkflows\Review\Assoc\ReviewRouting_Assoc_1065_Edit.xsn” xmlns:xsf=”http://schemas.microsoft.com/office/infopath/2003/solutionDefinition&#8221; xmlns:msxsl=”urn:schemas-microsoft-com:xslt” xmlns:xdUtil=”http://schemas.microsoft.com/office/infopath/2003/xslt/Util&#8221; xmlns:xdXDocument=”http://schemas.microsoft.com/office/infopath/2003/xslt/xDocument&#8221; xmlns:xdMath=”http://schemas.microsoft.com/office/infopath/2003/xslt/Math&#8221; xmlns:xdDate=”http://schemas.microsoft.com/office/infopath/2003/xslt/Date&#8221; xmlns:my=”http://schemas.microsoft.com/office/infopath/2003/myXSD&#8221; xmlns:xd=”http://schemas.microsoft.com/office/infopath/2003&#8243; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xmlns:xhtml=”http://www.w3.org/1999/xhtml&#8221; xmlns:aml=”http://schemas.microsoft.com/aml/2001/core&#8221; xmlns:dt=”uuid:C2F
Finally these are the flowing steps to translate a generic workflow form:

  • Get a copy of the form. It is in Features directory. For example for Review_Assoc:
    C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\ReviewWorkflows\Forms\ReviewRouting_Assoc_1033.XSN
  • Do the translation with InfoPath Save the file for 1065. For our example it would be ReviewRouting_Assoc_1065.XSN
  • Set the locale of the form on Persian if u like. This has no effect other than on Manage Form Templates if Centeral Administrator u’ll get correct form locale. But whatever locale u said, SharePoint is actually using te Form ID which should be corrected for 1065 (see below)
  • After completing the translation. Rename it with .Cab extension. Didn’t u know that? Inforpath forms are actually Cabinet compressed files.
  • You’ll find a MANIFEST.XSF file in the cabinet. Open it with note pad and edit it:
    • At the top of the file u’ll find a xsf:xDocumentClass tag. Within it u’ll get a name attribute. It should be corrected for the correct form name. Remember that when u edited the form template, InfoPath had automatically changed the form name here. It should be identical to that of english form name, just 1033 should be changed to 1065. For our example it would be:
      name=”urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Assoc:1065″
       
    • Just next to it u’ll find a publishURL attribute. Remove the attribute, i.e. delete it totally.

       
       

  • You should then Edit the Template.XML file. This file also contains a solution name that should be identical to the form name you set in the previous step. At the top of file, u’ll find a ?mso-infoPathSolution tag. Set the name attribute. For our example it would be:
    name=”urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Assoc:1065″
  • Now recab the form. U may use:
    Cabarc n ReviewRouting_Assoc_1065.XSN *.*
  • Copy the form to the soultion folder, where you picked the original 1033 version.
  • Now the feature should be reinstalled, so that the forms be installed with the feature. One may use STSADM to do that:stsadm -o deactivatefeature -name reviewworkflows -force -url http://babakserver 
    stsadm -o uninstallfeature -name reviewworkflows -force
    stsadm -o installfeature -name reviewworkflows
    stsadm -o activatefeature -name reviewworkflows -url http://babakserver

     

  • Sometimes it will be required so that you should Deactivate and re Activate the feature from Site Collection Features page.
  • To check if everything is ok go to SharePoint Central Administration \ Application Management\ Manage Form Templates. You should see somehing like this:
  • Note that the form should be Workflow Enabled.
  • Click on the 1065 version and use the View Properties option. You should see something like this:


  • Specially see the Form ID it should be exactly like what is shown here. Otherwise the form won’t be found.
  • Use the procedure for all forms in the workflow.

Now maybe you can see something like this:


 

Links:

http://www.gn.co.ir/KB/SharePoint/Lists/Posts/Post.aspx?ID=38

Written by Babak Mahmoudi

December 23, 2008 at 8:19 am

Posted in SharePoint

Tagged with ,

SharePoint Pack

leave a comment »

In this post I’ll introduce the SharePoint Pack Project. This is a project defined in Gostareh Negar (www.gn.co.ir) to develop a pack of useful SharePoint tools.

Project Statement:

SharePoint Pack is defined to provide a pack of SharePoint tools and utilities in a usable form. The tools and utilities are often share-ware available. The main effort is to gather these items in a usable format, e.g. providing samples, guidelines, installation helpers and so on. Therefore in general less effort would be put on the developing the items.

 
 

Position and evidence of needs:

There are many useful items here and there, for SharePoint. But these are less available in production lines. When one decides to use them, s/he should start from searching web, put time to select a suitable solution, then try to install and test it. The output of this project can help the end-users to save time in using a set of tested items together with the required documentation.

 
 

Scope Statement:

List of potential workproducts:

  1. Workflow activities
  2. Web Parts
  3. Field Types
  4. List Templates
  5. Site Templates

     
     

    As said above the main focus will be on wrapping the existing items and providing help. Therefore following requirements should be checked for work products:

  6. Less development effort. In general the required time of a potential item should be less than a week. Normally we should start with an existing code. If an item goes beyond this time limitation, most likely it wont be covered in the scope of SP Pack.
  7. Each work product should have a neat and simple documentation providing following information:
    1. Why to use: The information about why the product is required and in which cases it can be used.
    2. How to use: The information about how the item can be actually used together with samples.
    3. When to use: Information about limitations and possible problems.
    4. Technical Information : Technical backgrounds, issues and sources.

Written by Babak Mahmoudi

December 8, 2008 at 2:13 pm

Posted in SharePoint