A long requested feature of Event Broker has been the ability to quickly switch between configurations, or to run a different operation list under certain conditions. It would be useful for Event Broker v3 to finally allow for this, or alternatively, allow for more sophisticated branching under certain events (more easily configurable than label operations in v2.2.x).

A use case for the former would be switching between an operation list with logging operations enabled, and one without. This would be useful when testing system configuration using Event Broker to automate ILM/FIM attribute flows, without having to sit through unnecessary logging. Once testing has completed and the Event Broker configuration is migrated to the a production environment, the alternative operation list could be used. There are many cases like this where this would be useful

It should be intuitive and straight-forward to be able to switch between configurations

From QDET-207, it was asked if the clear run history plugin would clear out password change histories. It does not, but appears easy enough to do in the same way we do for clear run history. Carol linked to http://msdn.microsoft.com/en-us/library/windows/desktop/ms696072(v=vs.85).aspx which shows how.

Is there a benefit to having this as a plugin (or incorporated into the clear run plugin), instead of requiring a PowerShell script? Is this something that will be required at more than one site?

The synchronization cookie mechanism used by the AD Sync Changes mechanism can consume large amounts of memory, as the token seems to represent all changes present in the AD instance. This was investigated as part of EB-463 and found to be because of a FindAll call that is required for this mechanism to work (whereas a FindOne may retrieve each change until all changes are finally exhausted). Further investigation may be performed into:

• Any Active Directory level setting which may reduce the size of the cookie
• Programming constructs around the DirectoryServices namespace that will ensure large amounts of memory are not consumed
• Testing of FindOne to confirm whether or not individual changes only will be constantly retrieved, or if the token is successfully updated following a delta import

Perhaps because the application configuration is not set up properly for end-point. However, the agent check never failed at any point, and I'm too tired to go check the end-point configuration for Event Broker service.

Error message is:

Operation aefb9eb8-b07c-4331-97f8-f818af653f89 failed in operation list with id 24120bff-cc78-4154-80af-81d708957f0b for the following reason. This is retry number 2: System.InvalidOperationException: Could not find endpoint element with name 'IdentityBroker' and contract 'Unify.Framework.IChangesAvailableAdapter' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element.
at System.ServiceModel.Description.ConfigLoader.LoadChannelBehaviors(ServiceEndpoint serviceEndpoint, String configurationName)
at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName, Configuration configuration)
at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName)
at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address)
at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress)
at Unify.Product.EventBroker.IdentityBrokerChangesPlugIn.GetAdapter()
at Unify.Product.EventBroker.IdentityBrokerChangesPlugIn.Check()
at Unify.Product.EventBroker.StandardOperationListExecutor.RunCheck(ICheckOperationFactoryInformation checkOperation)

The LDAP Directory Changes operation fails with the following exception on execution:

Operation 7b4a99fd-d4f5-42e0-9349-b672b0a83882 failed in operation list with id a0daf801-7960-4946-80c2-1234c7f5672e for the following reason. This is retry number 0: System.ArgumentNullException: Value cannot be null.
Parameter name: sourceElement
at Unify.Framework.XElementExtensions.AttributeValueModify(XElement sourceElement, XName attributeName, Action`1 modifyAttribute)
at Unify.Product.EventBroker.LDAPAgentConfigurationFactory.CreateComponent(XElement factoryInformation)
at Unify.Product.EventBroker.OpenLDAPAgentFactory.CreateComponent(IAgentInformation factoryInformation)
at Unify.Product.EventBroker.AgentEngineRepository.<>c__DisplayClass13.<GetAgent>b__12()
at Unify.Product.EventBroker.ExtensionMethods.WaitOnMutex(Mutex mutex, Action work)
at Unify.Product.EventBroker.AgentEngineRepository.GetAgent[TAgent](Guid agentId)
at Unify.Product.EventBroker.OpenLDAPChangesPlugInFactory.CreateComponent(ICheckOperationFactoryInformation factoryInformation)
at Unify.Framework.ExtensibilityPlugInGenerator`4.CreateComponent(TFactoryInfo factoryInformation)
at Unify.Product.EventBroker.OperationListExecutorBase.RunCheck(ICheckOperationFactoryInformation checkOperation)

This is happening for the LDAP Listen operation too.

Confirm database operation can execute an Oracle stored procedure. The client stored procedure has two string input parameters and no output.

Download: http://www.oracle.com/technetwork/database/enterprise-edition/downloads/database12c-win64-download-1968077.html
Example data: http://www.java2s.com/Tutorial/Oracle/0540__Function-Procedure-Packages/Creatingaprocedure.htm

The following are a series of views for which invalid routing ids / values will cause errors:

• Edit action of the Agents controller, specifying a non-existent agent id or incorrectly formatted Guid. e.g. "Test"
• Create Schedule action of the Operation controller, specify a non-existant id or incorrectly formatted Guid.
• Operation Lists action of the Group controller, specifying an incorrectly formatted Guid.
• Logs action of the Logging controller, specifying an incorrectly formatted DateTime e.g. "Test"

An enquiry was received asking about Event Broker and auditing, in addition to other clients using Event Broker for transforming FIM audit drop files.

Please create a new plugin operation to transform FIM audit drop files (DSML).

Have a look at [~bob.bradley:Using Event Broker to archive exported changes for an MA].

Consider making a generic Xslt plugin. Supported input file type should be DSML; output html, W7 (TCIM) (csv and xml), configurable xslt.

The output files could be using built in xslt files, or possibly allow for other methods of transformation (a xslt transformation might not be the best method to create a csv).

This is related to task 236 https://unifysolutions.jira.com/browse/EB-236

Firstly I'd like to see a "test connection" button on the creation page, rather than going through with incorrect settings and finding out after the fact.

Secondly is there any reason you have to enter the password twice on the AD Agent and LDAPDirectory Agents. We aren't creating a new password, just authenticating, so to my mind you should only need to supply the password once.

I have managed to successfully configured

• Identity Broker Agent
• The corresponding Check Operation for Identity Broker Changes operation
• The run profile operation for "Delta Import and Delt Sync"

The Operation List is enabled and working.

When there is a change in the Identity Broker and the Operation being carried out successfully I cannot find any corresponding log entry for the Operations being performed in the log file.

I thought be perhaps by default it does not have the log filter level for logging this information. Thus I modified the Unify.Product.EventBroker.LoggingEnginePlugInKey.extensibility.config.xml to include the severity for "All" as below:

<?xml version="1.0" encoding="utf-8" ?>

<LoggingEngine changeId="

" logDaysKeep="5" filePrefix="UnifyLog">
<LogWriter name="AsyncLogWriterComposite">
<logFilter name="Severity" severity="All" />
<LogWriter name="Console" />
</LogWriter>
</LoggingEngine>

And restarted the Event Broker service.

In the FIM Sync Manager there are corresponding of FIM Operation log with status as success.

I still could not find any log entry in regarding to the Operation being performed in log file.

Did I missed something here or is this by design?