0
Answered

FIM Portal Incoming Operation list does not fire from v4 workflow after upgrade from v3.2.1

Bob Bradley 7 years ago updated by anonymous 7 years ago 6

Having installed the v4 EvB service and corresponding woirkflow activity, then updating the AIC and workflow definitions to correctly reference the latest signature, the workflow appears to run correctly in MIM but does not trigger the operation list corresponding to the configured GUID.  No exceptions are identifiable in any event or service log.

I know that the activity is being correctly referenced by MIM because the UI would otherwise not resolve, and the triggered request would fail.

This behaviour is consistent in both DEV and UAT after the upgrade:

The v3.2.1 workflow was working as required up until the time of the upgrade.

Are there any other components which need to be changed with this upgrade?

Answer

Answer
Under review

Hi Bob,

The only change I am aware of made to the Portal Workflow between v3.2 and v4.0 is Disable workflow checkbox in FIM Event Broker Workflow.

GOOD, I'M SATISFIED
Satisfaction mark by Bob Bradley 7 years ago
Answer
Under review

Hi Bob,

The only change I am aware of made to the Portal Workflow between v3.2 and v4.0 is Disable workflow checkbox in FIM Event Broker Workflow.

Ah - the http://voice.unifysolutions.net/topics/2004-disable-workflow-checkbox-in-fim-event-broker-workflow/ feature was the problem - I discovered that the 2 workflows I had configured were disabled.

Knowing the way MIM workflow definitions (XOML) work in regards to backwards compatibility, it makes sense that this happened ... so there will need to be a post-installation step for sites being upgraded from v3.*.

For new sites there is also a problem - I checked the generated FIMEventBrokerWorkflow.ps1 script from the Event Broker 4 operation list, and the $mimEventBrokerWorkflow variable has NOT been updated to include a new WorkflowEnabled="True" setting in the XOML.  This is something you will need to update in the product ... here is the exported XOML property from an activated workflow activity:

<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:Unify.Product.EventBroker;Assembly=Unify.EventBroker.PortalWorkflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=84b9288cb2633de4" 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:eventbrokerchangesactivity endpointconfigurationname="ServerNotifications" endpointaddress="http://d-occcp-IM301:59990/EventBroker/EventBrokerManagementStudio.svc" description="Invokes a specified Event Broker operation list. This activity should only be used to specify either an incoming operation list for the FIM Portal MA, or to point at a baselining operation list." workflowenabled="True" operationlistguid="6613ecf6-a2bb-4a26-bb8b-9913549bb9aa" operationlistname="{x:Null}" x:name="authenticationGateActivity1"></ns1:eventbrokerchangesactivity>
</ns0:sequentialworkflow>

I have reviewed http://voice.unifysolutions.net/topics/3177-mim-event-broker-400/ and can see the reference, but there were no upgrade notes explaining that this needs to be enabled (disabled by default after uppgrade).  What were the doco recommendations?  I've written a PS script which is under review too ... all of this info needs to be packaged nicely for external users to have a chance of a successful upgrade.

+1

Thanks for the feedback, Bob. I'm not sure if enabled or disabled is best by default, perhaps it's best to raise this as a feature request so we can consider it appropriately. In the mean-time, I agree that there should be mention of this fact so I'll update the release notes and documentation to mention this.

Thanks Curtis.  I don't believe there should be any doubt as to the correct status by default for an upgrade scenario, since v3.* was always ON.  For new installations I would also argue that ON makes sense (if I were to specify the design, it would have been a DISABLE checkbox for this reason) - however this was not a suggestion of mine and hence I was unaware.  Happy with the new feature, but it was an unexpected surprise and for other upgrade customers will no doubt cause issues unless this is patched.