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.
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.
string GetLocalizedFormUrn (string
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=»126.96.36.199″ productVersion=»12.0.0″ solutionFormatVersion=»188.8.131.52″ 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» xmlns:msxsl=»urn:schemas-microsoft-com:xslt» xmlns:xdUtil=»http://schemas.microsoft.com/office/infopath/2003/xslt/Util» xmlns:xdXDocument=»http://schemas.microsoft.com/office/infopath/2003/xslt/xDocument» xmlns:xdMath=»http://schemas.microsoft.com/office/infopath/2003/xslt/Math» xmlns:xdDate=»http://schemas.microsoft.com/office/infopath/2003/xslt/Date» xmlns:my=»http://schemas.microsoft.com/office/infopath/2003/myXSD» xmlns:xd=»http://schemas.microsoft.com/office/infopath/2003″ xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance» xmlns:xhtml=»http://www.w3.org/1999/xhtml» xmlns:aml=»http://schemas.microsoft.com/aml/2001/core» xmlns:dt=»uuid:C2F
Finally these are the flowing steps to translate a generic workflow form:
Now maybe you can see something like this: