0
Fixed

Pending Exports not firing corresponding Outgoing Operation List

Bob Bradley 8 years ago • updated by anonymous 3 years ago 25

Although ILM pending exports are present for an MA ("CIT AD") and a corresponding Outgoing Operation List is defined for this MA specified with (default) "Autorun on Outgoing Provisioning Pending", the export run profile "E" for this MA is never fired. The log (in Debug mode) shows no pending exports or any errors.


DEVAPP011VS.EvB.config.xml
EventBrokerLog.txt
OutgoingOperationList.EvB.Config.png
PendingExportsForAllMAs.Query.png
pendingExportsQuery.sql
PendingExportWaiting.png

Anton - this is what I believe to be a significant bug that will adversely affect the forthcoming version 3.0.0.

I therefore urgently request that this be included with the current release work.

Hi Bob,

If what you're saying is "this needs to be fixed for v3.0", then it almost certainly already is.

I believe Shane has pointed this out to you before, but every single line of code has been re-written. That is not an exaggeration - I literally mean that not a single line of code has made the transition from v2.2 to v3.0, and that we didn't even use the v2.2 codebase as a guide. Instances where v2.2 should have done something but didn't are likely to be a total non-issue in v3.0.

I am of course not suggesting there will be no new problems, but that is something we'll be working together to determine next month, and until then you shouldn't worry about technical defects carrying over.

I can confirm that the above theory is backed up by a positive result when I deleted and recreated the CS object in error. By deleting the object in AD I was able to invoke re-provisioning of the account. In doing so a new CS object was created with none of the "baggage" of the previous entry, and this time the existing Event Broker SQL query detected the presence of the pending export,

Patrick - that is good news, but this is more a design flaw in the existing outgoing changes detection SQL ... which would be unlikely to ever get detected without a fairly obscure scenario having occurred at 2 sites in the last 72 hours (DEEWR - reported by Jeff Nelson - and now InTACT). I think I have even pointed out this flaw before but it has got itself lost somewhere. In other words there's the Event Broker code base ... then there's the ILM SQL database characteristics which we are effectively reverse-engineering to detect changes. This is really under the "new learnings" categroy, rather than a bug in EB 2.3

P.S. Patrick - you're scaring me a little now ... for some reason I thought the 3,0 version was a rewrite of the UI only, but if it's the service too then I can only see a lot of pain ahead with having to go 2 steps back before we can take one step forward ...

We have issues assigned to review and re-write all the SQL queries present in the previous version - however, if you believe one of them needs to actually include additional functionality then that's another story and we'd be happy to work with you to examine such a change.

Regarding your second comment... the service was in an even worse state than the UI and had an incredible amount of flaws, both performance and maintainable-wise, from top to bottom. It is not something we could possibly have maintained or supported on a global scale. We have most definitely told you (in writing no less) that it's a complete rewrite (start here: INTEB:v3.0.0).

We are dedicating significant resources to ensure no functionality is lost (or alternatively that there is a suitable upgrade path) and the main purpose of input and feedback (not only from you, but the rest of the company and clients as well) next month is to ensure that this has been done accurately. Matthew, who as you know has had extensive experience with the previous version, has been working with the rest of us to examine and implement everything accordingly.

I'm happy to take this off-JIRA if you'd like, but for now I can assure you that we have have this covered and that in instances where a change is needed, we'll be able to make most changes in 5 minutes rather than 5 hours, or even days.

Bob, I've read over this a few times, and can't work out exactly what the error is, or what the scenario you've identified is. From what I can gather, the issue is either that the outgoing provisioning pending not detecting a pending export is not being presented in the logs, or that a pending export to Active Directory somehow miscalculated and did not register as a change. Can you please confirm?

Matt - the pending export to the CIT AD MA was not being detected because of an export error having occured at some stage previously for the same CS object (which has since been resolved). The detection algorithm is at fault here because it effectively does not take into account this scenario, and I believe the correction is a simple adjustment to the SQL query currently being used by Event Broker to check for pending exports. The symptoms are simply that no export is run when it should be, and there are NO errors in the log (nor does the log indicate in verbose mode that it has detected any pending exports either).

That's something to note. I'm guessing that the batch number in the database does not update. How did you fix the export error? Did you perform another sync so the same item was marked as a pending export? Or was it an export error that failed in communication?

The export was (I think) to do with an exchange 2010 mailbox provisioning failure (something I'm still working on). The problem was resolved by temporarily turning off mailbox provisioning. What gets left in the database is a NULL in the mms_connectorspace.is_export_error attribute (i.e. this BIT type attribute is nullable, and not always 0 or 1).

Thanks for the information Bob. If you believe this value being changed to null is a valid use case for the outgoing statement to register a change, we will have a look at this when we're revisiting the query. Can you please move this issue to the Event Broker project?

(Just using the "More Actions -> Move" feature)

Effects of new outgoing pending plugin relating to this issue to be seen in testing

Added the null check to the plugin, to be tested with the above scenario

Run some minor tests on this

There's actually an important piece of information from this - was a resync performed following the change? FIM marks the object as pending, and Event Broker will correctly ignore this until it is marked again by FIM as a pending export. Similar scenario occurs when an export error takes place

Assigned to Bob for feedback, please assign back to me after addressing the previous comment. Thanks.

Yes - the resync was done in an attempt to resolve the problem. It made no difference. The problem was with the SQL detection in Event Broker, not ILM. Yes - the scenario is the same as for an export error. Essentially we don't want the export to fire again after an export error without a resync having occurred first. If some other pending export is detected which triggers an export, and the export failure is repeated, that's fine. This was a specific scenario whereby it was IMPOSSIBLE to get Event Broker to fire on ANY subsequent change to this object once it had failed to export just once - i.e. this is a bug (the boolean attribute is tri-state).

Great, thank you for your very prompt reply to this. I've added the null check to the new query, but need to replicate the above scenario somehow. What would you recommend to check this issue has been addressed?

You need to cause an export error to occur for an individual connector (i.e. you don't want a BATCH failure). For me this was easily done by turning on exchange mailbox provisioning in the MA where there was a compatibility issue ... but there are any number of ways. One thing that comes to mind is exporting a mod to an AD object to which the FIM Sync MA has since been denied UPDATE rights (i.e. temporarily remove them from the object).

I have tried a similar scenario in attempting to export a change to Identity Broker while the service isn't running (resulting in an export error). This results in another export not firing, which seems to be correct given that the connector is marked as awaiting export confirmation, until a successful import flags the connector again as requiring an export. The alternative it would seem would be to continually attempt exports until a success was made.

Please let me know if this scenario is not adequate in testing your mailbox provisioning problem, as it sounds as if it is a different scenario.

Perfect scenario ... in the current Event Broker release this would be enough to prevent this export from being retried ever again if it was the only pending export waiting to go ...

Assigned to Bob for confirmation in next release

Have not seen this problem since the fix was available.