Search results matching tag 'Workflow'

ExpressionTranslator Error when publishing Workflows

ddobric — Tue, 26 Mar 2013 21:43:00 GMT

When working with Workflows, which running in Workflow Manager (SP devs call it usually SharePoint Workflow) on-premises or in Office 365 you might get following error:

Expression: DateTime.Now.ToString()

"Property access conversion to an activity is not supported for property 'CurrentDomain' defined on type 'System.AppDomain'."

This error occurs during Translation of the workflow. The translation is a step in process of publishing of the Workflow in Workflow Manager. it basically translates all expressions in Workflow Activities in a form
required by XAML, before the workflow is published (installed) to the host.

Following picture shows an expression which will cause described error:

The picture left below shows XAML expression which is translated in a bit different expression (picture right below). Note that DateTime.Now.ToString() is in this case not evaluated. It is a pure string like “BLA, BLA”.

   <Assign sap2010:WorkflowViewState.IdRef="Assign_1">
      <Assign.To>
        <OutArgument x:TypeArguments="x:String">
          <mca:CSharpReference
            x:TypeArguments="x:String">result</mca:CSharpReference>
        </OutArgument>
      </Assign.To>

      <Assign.Value>
        <InArgument
         x:TypeArguments="x:String">DateTime.Now.ToString()
        </InArgument>

</Assign.Value>

</Assign>

Right now, it is not possible to access properties within Expressions. To make this working you will unfortunately have to define the type to access properties. For example, if you want to access MyCustomTye.MyProp you will have to create the activity like GetMyCustomPropActivity and define InArgument<MyCustomTye> and OutArgument<yourproptrustedtype>. The later one will hold the value of MyProp.
This activity have to extend trusted surface (se URL below) even if the type is common .NET type like DateTime.

How to create custom activities:

http://developers.de/blogs/damir_dobric/archive/2012/09/16/workflow-trusted-surface.aspx

http://msdn.microsoft.com/en-us/library/windowsazure/jj193517(v=azure.10).aspx

Prepare Development Machine for Workflow Manager

ddobric — Thu, 14 Feb 2013 07:00:00 GMT

If you want to develop workflows for Workflow Manager, you do not have to necessarily install the full Service Bus and Workflow Manager server on development box. You can do this, but it is not required. To prepare you box go to this official download page: http://www.microsoft.com/en-us/download/details.aspx?id=35375 and download Client and Tools packages described below:

Workflow Client package:

Core Assemblies and API for Workflow Manager client applications including associated components Visual Studio 2012 tools.
Note that after installing of this package, no full VS support is installed. That means you will not have activity designer in VS toolbox.

Workflow Manager Tools for Visual Studio 2012
Provides the Visual Studio activity designers including SharePoint support, debugging and expression translation for Workflow Manager.

At the and following might be necessary too: http://developers.de/blogs/damir_dobric/archive/2012/12/13/how-to-export-servicebus-certificates-to-client-machines.aspx

Setting up authorization rights on Service Bus entities

ddobric — Thu, 31 Jan 2013 06:18:00 GMT

Service Bus for Windows Server provides two ways to setup access rights to its entities (queues/topics). Since the Windows Azure Access Control Service (ACS) is not available on Windows Server, the Service Bus for Windows Server includes a simple Service Bus Security Token Service (SBSTS). The SBSTS integrates with the Windows security model, and silently issues a Simple Web Tokens (SWTs) based on Windows identities (for domain users, or roles for domain groups).

If you setup the rights on the namespace-level the user will automatically get all permissions: Manage, Listen and Send. Additionally rights can be managed at entity level more precisely. When setting up rights on that level you have to deal with two different types of claims. Currently there are two types of claims supported. First type is used when the right is setup for domain user, and second one when the right is setup to domain group.
In general, both types can be described by short name and full name. Below are the supported types:

Domain Group claim type is called RoleType:

shortname: "role"

fullname: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"

Domain User Claim Type is called IdentityType:

shortname: "nameidentifier"

fullname: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"

For better understanding take a look on following example:

QueueDescription myQueue = new QueueDescription(QueueName);

AuthorizationRule identifierRule = new AllowRule("WorkflowDefaultNamespace","nameidentifier",
"username@yourdomain.com",new List<AccessRights>(){ AccessRights.Listen, AccessRights.Send });

myQueue.Authorization.Add(identifierRule);

AuthorizationRule groupRule = new AllowRule("WorkflowDefaultNamespace","role",groupname@yourdomain.com,
new List<AccessRights>(){ AccessRights.Listen, AccessRights.Send });

myQueue.Authorization.Add(groupRule);

namespaceManager.CreateQueue(myQueue);

This example adds the send and listen rights to one user and one group. Note that that the first argument (issuer name) can be obtained by command-let Get-SbNamespace. Usually this equals to the name of namespace. In my example I used the namespace of the Workflow Manager (“WorkflowDefaultNamespace”).

Following example shows hot enumerate rights:

QueueDescription q = namespaceManager.GetQueue(QueueName);

            var en = q.Authorization.GetEnumerator();

            while (en.MoveNext())
            {
                AuthorizationRule rule = en.Current;

                string rights = "";

                foreach (var r in rule.Rights)
                    rights += r;

Console.WriteLine("type:{0}, value:{1}, rights: {2}", rule.ClaimType, rule.ClaimValue, rights);
}

The official MSDN article which gives a better high-level overview: http://msdn.microsoft.com/en-us/library/windowsazure/jj193003(v=azure.10).aspx

Loading XAML from external location

ddobric — Tue, 29 Jan 2013 06:30:00 GMT

When working with XAML in general, like with Workflow or even WPF you might get following error:

Cannot create unknown type '{clr-namespace:YOURNAMESPACE}YOURCONTROL'.' Line number '' and line position ''.

This error will occurred if the XAML file is loaded from external location. In a case of WPF this would look like:

using (var reader = new StreamReader(XamlFile))
{

      UserControl control = (UserControl)XamlReader.Load(reader.BaseStream);
      control.Name = "m_MyExternalControl";
      this.AddChild(control);
}

When loading XAML files this way all namespaces in XAML have to be fully qualified. Usually Visual Studio designer holds project references to all controls as long the control (XAML) is bound to project and the
BuildAction (in property windows of XAML file) is set on ‘Page’. That means tha VS has enough information about control and XAML. Because of that VS will shorten the namespace as shown in following XAML snippet:

Unfortunately, when you take this control (XAML-file) out of project and load it by XamlReader as shown above the control will fail compilation right after load process ha been completed.

Cannot create unknown type '{clr-namespace:MyCustomControls}MyControl.' Line number '' and line position ''.

To fix this you simply need to add the full qualified assembly name of the control:

SharePoint WorkflowManager error: Cannot create scope

ddobric — Thu, 06 Dec 2012 21:29:00 GMT

When trying to create the scope you might sometimes notice following error.

Scope '/myscope/’is not in an active state. Its current state is 'Unregistering'. HTTP headers received from the server - ActivityId: ..

This can happen if you have previously deleted the child scope ‘myscope’. Under some conditions unregistering of scope can take very long time, here long sometimes can be forever.

Following calls will cause this error:

client.CurrentScope.PublishChildScope(../myscope/..);

or

client.Activities.Publish(..activity/..);

or

client.Instances.Terminate(inst.WorkflowName, inst.InstanceName, "Admin");

To workaround this problem, one SQL Management studio and connect to the machine which hosts the Workflow Manager database.
Then carefully execute following statement:

update [WFResourceManagementDB].[dbo].[Scopes] set [Status] = 'Active' where [Status] = 'Unregistering'

NOTICE: The statement shown above is not supported by Microsoft and can possibly damage your system!!!

I did that several time and it worked all fine. Anyhow if you decide to fix it this way it is on your own responsibility.

How to setup Service Bus permission ?

ddobric — Tue, 04 Dec 2012 15:21:00 GMT

When working with ServiceBus for Server, the setup is responsible to define default user’s permissions. During setup procedure you will have to provide the credentials of the user who will be admitted to host and to manage Service Bus.
However permissions for Workflow Manager are managed a different way. During installation of the Workflow Manager you will have to provide the name of the group of users (by default BUILIN\Administrators) who can manage the Workflow Host.
This will setup the permissions for user who can manage Workflow Host. But note this will not setup permissions for Service Bus namespace. This is so far not a limitation, because in a case of Workflow Host you will usually not deal with Service Bus Namespace directly. Even more the namespace behind Workflow Host is more or less a hidden artifact.
But sometimes there are scenarios especially with ServiceBus in play, which enable you to do powerful things by dealing directly with Service Bus. You can this way extend the functionality of the Workflow Host. This might be in the future a valid and possibly lovely scenario for SharePoint developers.

If so, you will have to change permissions of the namespace of the Workflow Host in the Service Bus itself.Before you start type Get-SBNamespace WorkflowDefaultNamspace. This Power shell command shows the current state of the default namespace assuming this is the namespace which you want to manipulate).

Name                  : WorkflowDefaultNamespace
AddressingScheme      : Path
CreatedTime          : 11/28/2011 1:56:25 PM
IssuerName            : WorkflowDefaultNamespace
IssuerUri                : WorkflowDefaultNamespace
ManageUsers           : {appfabriuser@daenetlab.lan, bahro@daenetlab.lan}
DnsEntry              :
PrimarySymmetricKey   : ABC…DEF..OBFUSCATED=
SecondarySymmetricKey :

As you see there are two users permitted to manage the namespace. appfabricuser and bahro. Both are from the same domain daenetlab.lan.
If you want to extend permission to additional user (i.e. damir) do following:

PS C:\Program Files\Workflow Manager\1.0> set-sbnamespace -ManageUsers appfabr
csuser@daenetlab.lan, bahro@daenetlab.lan, damir@daenetlab.lan

Execute Get-Namespace again and here we are:

Name                  : WorkflowDefaultNamespace
AddressingScheme      : Path
CreatedTime          : 11/28/2011 1:56:25 PM
IssuerName            : WorkflowDefaultNamespace
IssuerUri                : WorkflowDefaultNamespace
ManageUsers           : {appfabriuser@daenetlab.lan, bahro@daenetlab.lan, damir@daenetlab.lan}
DnsEntry              :
PrimarySymmetricKey   : ABC…DEF..OBFUSCATED=
SecondarySymmetricKey :

New user has been added and this namespace can be used now for custom extended scenarios on top of your already used namespace.

Deploying of the new version of SharePoint Workflow

ddobric — Tue, 04 Dec 2012 07:58:00 GMT

Assume you have an activity which is executing for very long time. This is so called Long-Running workflow. In fact long-running scenario is one of scenarios in Commuter Sciences which practically can very easy be solved by Using Microsoft Workflow Foundation.
Following workflow show never ending workflow which is often used in Integration scenarios where some kind of listening or long-polling need to be implemented.

The question in this post is: “After this workflow is started, what happens with this workflow when SharePoint deploys the new version?”. This is usually the case when some bug has been fixed or some new feature has been implemented.
During deployment of the new version SharePoint will not take a care about running instances. Instead, all running instances of the version N will be terminated with following error:

The instance has been terminated because the workflow associated with this instance is no longer available.

After this has happened, the new version N+1 is (should be) deployed and ready to start. Currently it is not clear (to me at least) if there is a way at all in SharePoint to figure out such issues. Fortunately Workflow Manager provides way to figure out such issues.
Following code shows how we do that. Just call enlistInstancesInState(…) to obtain all workflows in specified state.

private static void enlistInstancesInState(WorkflowInstanceStatus status)
{

                enlistAllScopes(null, (client) =>
                {
                    var cnt = client.Instances.GetCount();
                    if (cnt > 0)
                    {
                        foreach (var wfInst in client.Instances.Get(0, cnt))
                        {

if (WorkflowInstanceStatus.NotSpecified != status && wfInst.WorkflowStatus == status)
traceOutWorkflow(wfInst);

                            else if (WorkflowInstanceStatus.NotSpecified == status)
                                traceOutWorkflow(wfInst);
                        }
                    }
                });
        }

        /// <summary>
        /// Enlists all scopes starting at root.
        /// </summary>
        /// <param name="scopeRoot">Scope to be enlisted.</param>
        private static void enlistAllScopes(WorkflowManagementClient client, Action<WorkflowManagementClient> action)
        {

if(client == null)
client = getWfMgmClient(null);

if (action != null)
action(client);

var scopes = client.CurrentScope.GetChildScopes();

            foreach (var childScope in scopes)
            {
                enlistAllScopes(getWfMgmClient(Path.Combine(m_Root.TrimEnd('/') + childScope.Path)), action);
            }
        }

        /// <summary>
        /// Creates the instance of the WF-client.
        /// </summary>
        private static WorkflowManagementClient getWfMgmClient(string scope)
        {

WorkflowManagementClient client;

            if (scope == null)
                client = new WorkflowManagementClient(m_Root);
            else
                client = new WorkflowManagementClient(scope);

return client;
}

How do SharePoint 2013 Workflows look like under the hub?

ddobric — Thu, 29 Nov 2012 07:40:00 GMT

To get a feeling how SharePoint Workflows look like under the hub take a look on following example: http://developers.de/media/p/422263.aspx.
This is the original XML which fully (natively) describe the workflow deployed by SharePoint.

Following picture shows a snapshot of the XML which can be downloaded above:

Note that the dump shown above describe the WorkflowDescription without activities. However notice that description contains the reference to activity ActivityPath.
Similarly you can dump activities as follows:

http://host:12291/SharePoint/default/eac2871d-0758-4a2e-8b03-c02598c63c0b/8256fccd-21e8-4435-8327-2affb3234c23/$Activities

This call will return list of activities by their name. For example: WorkflowXaml_78ba2e34_c23f_4ea9_94fb_86d3efcd3c80
That name can be used to obtain the original XAML
http://host:12291/SharePoint/default/eac2871d-0758-4a2e-8b03-c02598c63c0b/8256fccd-21e8-4435-8327-2affb3234c23/$Activities/WorkflowXaml_78ba2e34_c23f_4ea9_94fb_86d3efcd3c80

And finally, here is the result which dups out the XAML of the workflow:

Examples shown above has been taken out of Workflow Manager which is running on Premise. However same or similar workflow descriptions are used when running in Office 365 and Windows Azure.
I will describe the meaning of all of required artifacts in my future blog posts.

SharePoint Workflow TrustedSurface

ddobric — Mon, 26 Nov 2012 07:23:00 GMT

As I described here Windows Azure Workflow (Workflow Manager) is originally designed to run in the cloud. That means it designed as multitenant application. because of that the Workflow Manager must fulfill several very sensitive security requirements. One of used approaches is so called “Reduced Trusted Surface”. This means that subset of common primitive types is supported only. Unfortunately SharePoint requires many activities which are not the part of Trusted Surface of Workflow Manager.
For this reason, SharePoint team has extended the Type System of the Workflow Manager.
The list shown below is the full list of all SharePoint custom activities which extends the default Trusted Surface described in the post above:

MatchesString IsLessThanOrEqualDateTime IsLessThanDateTime IsGreaterThanOrEqualDateTime IsGreaterThanDateTime IsEqualUser IsEqualStringIgnoreCase IsEqualDynamicValue IsEqualDateTime IsEqualDate ContainsStringIgnoreCase WriteToHistory WorkflowInterop WordsInTitle WaitForItemEvent WaitForFieldChange	WaitForCustomEvent UpdateListItem UndoCheckOutItem TranslateDocument SetWorkflowStatus SetTimeField SetRelatedItem SetField ReplaceEmailTokens RegisterForSharePointEvent ModifiedInRange ModifiedBy LoopNTimes LookupWorkflowContextProperty LookupSPUserProperty LookupSPUser
LookupSPTaskListItemAssignedTo LookupSPTaskAssignedToDisplayName LookupSPPrincipalProperty LookupSPPrincipalId LookupSPPrincipal LookupSPFields LookupSPField LookupSPListProperty LookupSPListItemStringProperty LookupSPListItemSPFieldLookupProperty LookupSPListItemSPFieldLookupMultiProperty LookupSPListItemPropertyNameInREST LookupSPListItemProperty LookupSPListItemInt32Property LookupSPListItemGuid LookupSPListItemDynamicValueProperty LookupSPListItemDoubleProperty LookupSPListItemDateTimeProperty LookupSPListItemBooleanProperty LookupSPListItem	LookupSPList LookupSPGroupMembers LookupSPGroup LookupSPChoiceFieldIndex JoinSPPrincipalPropertyFromInitFormParamUserMulti JoinSiteUserInfoListPropertyFromSPFieldUserMulti JoinIdOrValueFromSPFieldLookupMulti JoinChoicesFromSPFieldMultiChoice IsValidUser IsSPListItemPropertyLookupToDocsField GetHistoryListId GetTaskListId GetCurrentListId GetCurrentItemGuid GenerateEmailDynamicValue ExtractSubstringFromIndexLength ExtractSubstringFromIndex ExtractSubstringFromStart ExtractSubstringFromEnd ExpandInitFormUsers
ExpandGroupToUsers Email DeleteListItem DelayUntil DelayFor DefaultRetryPolicy DateInterval IsNull WebUri CreateListItem CreatedInRange CreatedBy CopyItem ConvertPropertiesForSPListItem CompositeTaskHelper	CompositeTask Comment CheckOutItem ConvertTimeZoneFromUtcToSPLocal BuildSPUri ConvertTimeZoneFromSPLocalToUtc CheckInItem CallHTTPWebService Calc BuildSPListItemWebLink AtomicTaskItemUpdatedHelper SingleTask AppOnlySequence

All of activities are deployed to following scope:
http://spswfmanagermachine:12291/sharepoint

Note that SharePoint Workflow Manager by default also installs the scope ‘default’ (http://spswfmanagermachine:12291/sharepoint/default)
This scope currently does not contain any activity.

When working with Workflows in Office 365, these activities are present by default too.

Deployment of Workflows in Workflow Manager

ddobric — Sun, 18 Nov 2012 10:48:51 GMT

When deploying Workflows within Workflow Manager as long activities inside of trusted surface are used, there is no assembly which should be referenced or published to the host.
All required is contained in a XAML.

Usually one workflow is WorkflowDefinition which basically defines the activation envelope of the around the activity.
That means one workflow is defined by two XAML-s: Activit.Xaml and Workflow.Xaml.
Activity.Xaml fully implements the workflow in XAML. Workflow.Xaml defines configuration, activation, etc. and sets the reference to Activity.xaml which will be executed.

So, Deployment is two-phase process:

client.Activities.Publish(Activity.Xaml) and

client.Workflows.Publish(Workflow.Xaml);

As we see, first root activity is published to the manager database and then the workflow envelope (workflow description) itself. This is because, Workflow has a dependency to root activity, so activity has to be deployed first.
As long you use build-in activities defined by trusted surface there is no need for any assembly to be deployed. All you have and need is declarative XAML.
However in a case of extending of trusted surface, fist assemblies which implement custom types have to be deployed. After they are deployed, workflow publishing works as already described above.

To get a feeling about publishing open the browser and paste following:

GET //SharePoint/default/eac2871d-0758-4a2e-8b03-c02598c63c0b/8256fccd-21e8-4435-8327-2affb3234c23/$Workflows?$skip=0&$top=100

Note, the underlined part is the scope path of workflow at your machine (this one is example from my machine). This statement is a REST call to Workflow Manager which will return up to 100 installed workflow definitions.
Similarly following REST call would get the full Workflow Description of workflow with name=’ d1991cf0-0fa3-46d7-9cf7-32014141c6aa‘:

GET //SharePoint/default/eac2871d-0758-4a2e-8b03-c02598c63c0b/8256fccd-21e8-4435-8327-2affb3234c23/$Workflows/d1991cf0-0fa3-46d7-9cf7-32014141c6aa

There is also a REST call which can dump-out the whole XAML implementation.

http://host:12291/yourscope/$Activities/WorkflowXaml_78ba2e34_c23f_4ea9_94fb_86d3efcd3c80