FIM Event Broker Portal Changes - Multiple Approval Updates Not Triggering Run Profiles

Assigned to Matthew.

Hey Richard,

I've had to have a good think about this one, as we don't really have the "best practices" locked down for the portal workflow just yet - we're still in the process of forming those as we have more implementations using Event Broker 3. I have only seen the workflow configured on action workflows so far (as described in the documentation), with it configured on similar MPRs to "Administrators can create or modify data resources" or rule changes, and have not considered using it on an approval workflow. The nature of the workflow is that it will attempt to fire an operation list the instance it runs, and does not continue in an awaiting state in FIM Portal. This is because of a number of reasons, such as having potentially numerous workflows sitting in FIM Portal awaiting external processing, and also because the alternative of queuing the operation lists would result in excessive execution of the operation list.

I'd be curious to know your requirements in having the workflow on an approval workflow, as we have not considered this use case.

Please get back to me with your thoughts

It may also be useful if anyone else has any thoughts on the use of the portal workflow on approval workflows

Hi Bob,

Are you able to assist with this?

Thanks.

Richard

I concur with Matt that the only configuration for this workflow that I have worked with so far is an ACTION workflow, and I believe this is the appropriate usage in your scenario too.

The architecture of FIM dictates that when an MPR is attached to both an AuthZ and Action workflow, the AuthZ has to succeed before the Action can take place. This model has to be consistent for both the "one of many to approve" and "all of many to approve" approval routing options. Either way, the logical place to attach the workflow to your MPR is to the ACTION phase, because in the latter of the above approval models, I could have 4 approvals and one (the 5th) a rejection, in which case the action will never run ... which is what you want in this scenario.

The easiest way to conceptualize this is to think of what the FIM MA will see ... if there is any rejection in the AuthZ step then there will be nothing in the delta import at all.

Please call me on 0438 181003 to discuss if you wish, because I'd be interested to know why you think you should be attaching to the AuthZ phase.

Hi, just to clarify, this (Event Broker Changes) is still an action workflow but there is also an approval workflow on the same MPR. The action gets triggered after the approval workflow is approved.

I have it configured this way for DPS as on paper it was a nice and clean solution, the FIM MA only had to run a delta if something had changed which for DPS also involves an approval process for self service requests. DPS seems keen to have as much happening as close to real time as possible too.

Two things but.
1) Firstly given there is a manual approval process in this workflow the "real time" behaviour probably means nothing other than looking good on paper. In reality changes will only happen as quick as the staff are to approve them. Therefore I'm prepared to go back to DPS and discuss just making this run at 15 minute intervals or whatever. In the scheme of things it won't be a great delay to the overall process and will only affect self service changes.

2) It does however make me want to at least get confirmation that this isn't a timing issue with Event Broker that could affect other sites. Even if an approval workflow is not used, what will happen on another site during a busy period if multiple users independently perform an action that would cause the Event Broker Changes plugin to fire. Will we see the same result as I am seeing when multiple approvals are triggered in quick succession?

With a bit more testing I noticed that if I have a larger number of pending request (say 16) that take a while to complete, A second delta import may trigger if the first one completes before the overall approval process is complete. I have had some runs where over 16 approvals I may get 3 Delta Runs triggered in the FIM Sync Service. First will have one delta import, the second may have five.

I can look to get more refined timings on all this if you like. Currently I just had FIM and the FIM Portal open side by side...not very scientific I know.

edit: As far as DPS is concerned, for now I'm testing a scheduled delta. There is also a nightly Full Import Full Sync scheduled.

Hi Bob. Please see the above. I may have made a hack of describing it.

The Event Broker Changes is an Action Workflow which triggers after an additional Authz workflow.

I'll get a screengrab and attach

screenshot attached

If this is what you're talking about, then you will need to adopt the same approach as I did @ DEEWR. I have raised this as a defacto "best practice" with the UNIFY PG already ... in the absence of a better mechanism with the current version of EvB.

That sounds like it. Thanks

Might I suggest adding this here: https://unifysolutions.jira.com/wiki/display/EB300/Troubleshooting

I had a look prior to raising the question and didn't see anything

Beyond that, I'm satisfied with the answer

Updated billing key

Hey guys,

Thanks for your feedback on this issue. The documentation is then correct in stating that an action workflow should be configured, and I will leave this intact. However, the issue of configuring the second FIM agent had not yet been documented. I have added this both to the troubleshooting page and to the EB300:Configuring the Event Broker Changes Activity. Please confirm if this is appropriate for you.

Matt - you have indeed captured the essence of the change, but I fear that there are some knock-on affects of this configuration that also need to be understood:

• After introducing a secondary FIM MA, the Event Broker administrator will be prompted to nominate which agent is required whenever either modifying an existing run profile operation, or creating a new one. While this sounds sensible enough, the problem here is that unless the 2 agents are sensibly named then the administrator can accidentally select the wrong agent without any immediate visible side-effects (but obviously this will have an unexpected impact). For future versions of Event Broker a more configuration-friendly approach should be looked at. See PRODUCT-16 for the DEEWR configuration to see how many operations can be affected.
• Although you have not explicitly stated this, the implications of removing the "no-start-ma-already-running" are significant in terms of the Event Broker log (I discussed this in another issue EB-381). The most significant impact is in terms of the FIM Requests failing with a ProcessingError status when they used to succeed previously (can cause undue angst for the admin, and create a lot of noise in the Request history which might mask a REAL issue). The secondary impact is in the Event Broker logs themselves which will now show what is essentially a warning as an error ... again, masking real errors.

In other words, the above configuration gets us by for now, but not without side effects which may be considered undesirable at some sites.

Assigning to you matt in case you want to review Bobs suggestions. I'll close the question afterwards

Thanks for your investment into this guys.

Regarding the first issue you raised Bob, I have updated the documentation on the EB300:Agents page to stress the importance of an aptly named agent.

Regarding the second, Event Broker was updated as a result of EB-381 such that the Portal Workflow will not throw all its errors to the Request History, but rather only in the Event Broker logs. I have noted this and also fleshed the troubleshooting section out a bit more effectively by adding a EB300:Usage Considerations article, making recommendations for configuring the workflow. Bob/Richard, if you wouldn't mind confirming these are consistent with your experiences, I'm sure this will go a long way to assisting users in the future.

Please close this issue if you think the documentation is appropriate and clear.

Re-resolving issue, see above comment.

I'm happy with all that. If you are Bob feel free to either reassign to me or close yourself

Happy with the resolution, now that EvB has been updated recently to prevent the FIM Workflow instances from failing the associated FIM Request (where EvB is invoked such that the "no-start-ma-already-running" status is treated as an exception rather than a warning), as well as the documentation having been updated accordingly. Notwithstanding this, there is still room for improvement in the way that this scenario is handled (i.e. it would be better in the long run if only a single agent was required somehow).