[//Request/Target] not resolved in combination with CompositeRequests

[weyto]

Hi Nilesh

We struggling over an issue in the last days, where the actual release not resolve [//Request/Target]. In older Versions in case of a PostProcessing Request after a Object Deletion the Target Object ID could be resolved over the Request (Attribute Target).
This is only in a constellation of a CompositeRequest, and there it is the same if it is a PostProcessing after deletion or modify.
We tried [//Request/Target], [//Request/RequestParameter/Target] and of course [//Target] but in case of a PostProcessing after a Deletion that can't be used successfully.

We haven't yet invest time to look into the Source Code. But do you know, if this is an result of the investment from Version v2.16.0320.0?

We want to know your opinion before we invest many hours in this.

Thanks a lot for you answer
Thomas

[NileshGhodekar]

If this is not working for CompositeRequest, then probably it never worked for Delete operation. What do you see for returned [//Target] in the verbose log?

[weyto]

The first event what i see is:

There you see the TargetID which was the deleted Object.

The second Event is the PostProcess itself.
There you see the TargetID is still the deleted Object. (Note this is only a troubleshooting workflow which will report some Workflow values in a static user. (See Appendix)

After that i received Event 3 as Error.

Interesting is, that in the Workflow Activity no [//Target] is used. We only go over the Request Object and want the Attribute Target in the Request. So only [//Request/Target] and [//Request/DisplayName] was used for Source Attributes. (See XOML code as Appendix.)
Note [//Request/DisplayName] only in the Activity run also in a exception.
It looks like that everything isn't working in case of Composite Delete, because also a static value could not be written in a other Object in this case.
But i wondering why this is working in a non Composite Szenario!?

Appendix XOML:
<ns0:SequentialWorkflow ActorId="00000000-0000-0000-0000-000000000000" RequestId="00000000-0000-0000-0000-000000000000" x:Name="SequentialWorkflow" TargetId="00000000-0000-0000-0000-000000000000" WorkflowDefinitionId="00000000-0000-0000-0000-000000000000" xmlns:ns1="clr-namespace:MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.Activities;Assembly=MicrosoftServices.IdentityManagement.WorkflowActivityLibrary, Version=2.17.414.0, Culture=neutral, PublicKeyToken=589776d82beb770c" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow" xmlns:ns2="clr-namespace:MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.ComponentActivities;Assembly=MicrosoftServices.IdentityManagement.WorkflowActivityLibrary, Version=2.17.414.0, Culture=neutral, PublicKeyToken=589776d82beb770c" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:ns0="clr-namespace:Microsoft.ResourceManagement.Workflow.Activities;Assembly=Microsoft.ResourceManagement, Version=4.4.1459.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<ns1:UpdateResources x:Name="actionActivity1" ActivityExecutionCondition="" ActivityDisplayName="get WF" Iteration="" ActorType="Service" ApplyAuthorizationPolicy="False" ResolveDynamicGrammar="False" QueryResources="True" Advanced="True" ActorString="">
ns1:UpdateResources.UpdatesTable
<ns3:Hashtable xmlns:ns3="clr-namespace:System.Collections;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<ns4:String xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">[//Queries/me/ProxyAddressCollection]<x:Key>ns4:String1:1</ns4:String></x:Key></ns4:String>
<ns4:String xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">InsertValues([//Request/Target])<x:Key>ns4:String1:0</ns4:String></x:Key></ns4:String>
<ns4:Int32 xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">2<x:Key>ns4:StringCount</ns4:String></x:Key></ns4:Int32>
<ns4:Boolean xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">false<x:Key>ns4:String1:2</ns4:String></x:Key></ns4:Boolean>
<ns4:Boolean xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">false<x:Key>ns4:String0:2</ns4:String></x:Key></ns4:Boolean>
<ns4:String xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">InsertValues([//Request/DisplayName])<x:Key>ns4:String0:0</ns4:String></x:Key></ns4:String>
<ns4:String xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">[//Queries/me/ProxyAddressCollection]<x:Key>ns4:String0:1</ns4:String></x:Key></ns4:String>
</ns3:Hashtable>
</ns1:UpdateResources.UpdatesTable>
ns1:UpdateResources.QueriesTable
<ns3:Hashtable xmlns:ns3="clr-namespace:System.Collections;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<ns4:String xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">/Person[AccountName = 'martin.kaufmann']<x:Key>ns4:String0:1</ns4:String></x:Key></ns4:String>
<ns4:Int32 xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">1<x:Key>ns4:StringCount</ns4:String></x:Key></ns4:Int32>
<ns4:Boolean xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">false<x:Key>ns4:String0:2</ns4:String></x:Key></ns4:Boolean>
<ns4:String xmlns:ns4="clr-namespace:System;Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">me<x:Key>ns4:String0:0</ns4:String></x:Key></ns4:String>
</ns3:Hashtable>
</ns1:UpdateResources.QueriesTable>
</ns1:UpdateResources>
</ns0:SequentialWorkflow>

[NileshGhodekar]

The difference with the composite request is that the request data for the workflow requests is in a single parent request, so it needs special handling to ready the request information for the individual workflow request.

Can you try three separate and very simple action workflows doing only one of the single lookups below each (you can fire them all in single MPR):

1. IsPresent([//Request/Target]) => [//WorkflowData/RequestTarget]
2. IsPresent([//Request/DisplayName]) => [//WorkflowData/RequestDisplayName]
3. IsPresent([//Target]) => [//WorkflowData/Target]
   I've added IsPresent so that you can quickly search in the event log for results.

From what you are saying, 1 - results in "target does not exist error" - not expected, but looks like a FIM/MIM thing unless the WAL code is trying to read ObjectId attribute which is also not available, 2 - results in error- this is not expected - what error you get? 3 - I expect should give you the result unless this is resolving to parent request itself.

Can you send back the results?

[makauf]

Hi Nilesh

All three Workflwos finished successfully, also showing the results from the IsPresent function in the Eventlog as expected:

Until this point, it looks working..

But, i have now added a second update activiety to one of these workflows, trying to write [//WorkflowData/RequestTarget] into another object.

I therfore used a lookup query to search for my user and [//WorkflowData/RequestTarget] => [//Queries/me/Description] and expect to see "True" in my description - but then I receive "Value cannot be null exception".

please let me know if you want to see more eventlogs / results.

[NileshGhodekar]

This is then likely the problem with the query itself. Do you see query returning valid resources (11204 events?

[makauf]

you're right, i don't get any 11204 events.
But the same lookup is successfully when the a single deletion is made (or in other words, no composite request is used).

Event 1 (through composite request)

Event 2 (single - no composite request)

Event 3 (successfull lookup)

[NileshGhodekar]

That would be really strange! If this is a new activity that only consumes WorkflowData then it does not have any connection to the deleted object processing in the previous object. Looks likes issue with simply using queries in the Composite delete request workflow.

PS: The message "the expression ... is invalid" is informational and was changed to Verbose logging level in the latest release.

[Pierre-Wo]

Can confirm, the bug does still exist. It does not seem to have anything to do with the lookup of the target object or the query syntax though. As soon as the query feature is activated, and therefore at least one query defined, it will run into an error. But only when it runs for composite delete requests, everything else works.

I tried different queries, and even with a single query for all person objects, or a static person, will result in an error. In the update part I just write a constant string into a variable or WorkflowData.

Removing the check mark for "Query Resources" allows the Workflow to finish without errors.

These are the Workflow Status Details of the failing Workflow Instance, maybe it helps?

EXCEPTION DATA
MESSAGE: Value cannot be null.
Parameter name: The target object of the operation no longer exists.
**METHOD:System.Exception ThrowException(System.Exception)
**METHOD:Void .ctor(Microsoft.ResourceManagement.WebServices.WSResourceManagement.RequestType, Microsoft.ResourceManagement.WebServices.WSResourceManagement.ResourceType, Microsoft.ResourceManagement.WebServices.WSResourceManagement.ResourceType, System.Collections.Generic.IDictionary`2[System.String,System.Object], Boolean, Boolean)
**METHOD:System.String ResolveLookupGrammar(System.Guid, System.Guid, System.Guid, System.Collections.Generic.Dictionary`2[System.String,System.Object], Boolean, System.String)
**METHOD:System.Workflow.ComponentModel.ActivityExecutionStatus Execute(System.Workflow.ComponentModel.ActivityExecutionContext)
**METHOD:System.Workflow.ComponentModel.ActivityExecutionStatus Execute(T, System.Workflow.ComponentModel.ActivityExecutionContext)
**METHOD:System.Workflow.ComponentModel.ActivityExecutionStatus Execute(T, System.Workflow.ComponentModel.ActivityExecutionContext)
**METHOD:System.Workflow.ComponentModel.ActivityExecutionStatus Execute(System.Workflow.ComponentModel.Activity, System.Workflow.ComponentModel.ActivityExecutionContext)
**METHOD:Boolean Run(System.Workflow.ComponentModel.IWorkflowCoreRuntime)
**METHOD:Void Run()

[HolgerWurbs]

Stumbled upon this bug as well, appears to be present in the latest version.

This Activity Execution Condition can be used to prevent Workflows from being executed on delete (single or Composite Delete):

Not(Or(Eq([//Request/Operation],"Delete"),And(And(Eq([//Request/Operation],"SystemEvent"),Eq([//Request/ParentRequest/TargetObjectType],"msidmCompositeType")),Eq([//Request/ParentRequest/Operation],"Delete"))))

But as soon as Query Resources is ticked on an update activity the workflow will fail with an "internal error" caused by a null reference exception because Query Resources causes the Target to be resolved and because the request operation in this case is SystemEvent and not Delete. The Resolver constructor will throw this exception by default if the target is null and the Operation is not Delete and not Create. The Resolver should be triggered with the parent request operation instead. I could track this down to the exact code line in MIMWAL if anyone is still maintaining this...

For now I circumvented the issue by running a query with a powershell activity...