Looking at testing the SAP connector for IdB at a customer (in a DEV lab) and getting a little confused as to what versions I should use. I was going to go with IdB 5.1 RC2, but can only find one msi file under https://unifysolutions.jira.com/wiki/display/SUBIDB/Downloads and when I run it it is the x64 version.

The prerequisites for SAP HCM connector v5.1 state that the 32 bit version of Identity Broker must be used https://unifysolutions.jira.com/wiki/display/IDBSAP51/Prerequisite

Where do I get the 32 bit version, or do I need to select an earlier IdB version (e.g. 5.0.4)?

I'm getting "HTTP status 502: Bad Gateway" trying to connect to Aurion to either retrieve schema or data. It hasn't worked previously as this is a new solution.

While it sounds like a network error it does look like IdB can talk to Aurion - if I deliberately mis-spell the Query name I get this error: "Query xx was not found". When the Query name is correct I get the 502 error.

What else can I do to troubleshoot this? I tried enabling IdB trace logging and reproducing the error, but there's nothing in the trace at all - ie searching on the Aurion URI address or the error message gets no results, and I can't see any errors in the trace.

This is the full error from the IdB log file:

System.Net.WebException: The request failed with HTTP status 502: Bad Gateway.at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Unify.Communicators.AurionAPI.EV397_AURION_WSService.CALLFUNCTION3(String P_TOKEN, String P_FUNCTION, String P_DELIMITER, String P_WRAPPER, String P_PARAMETERS, String& P_OUTPUT, String& P_MESSAGE, Decimal& P_STATUS)
at Unify.Communicators.AurionWSCommunicator.CallFunction(String function, IEnumerable`1 values)
at Unify.Communicators.AurionAgent.QueryToXml(String queryId, String expectedObjectName)
at Unify.Connectors.AurionApiReadingConnector.<GetAllEntities>d__5.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Unify.Product.IdentityBroker.AuditReadingConnectorDecorator.GetAllEntities(IStoredValueCollection storedValues, CancellationToken cancellationToken)
at Unify.Product.IdentityBroker.EventNotifierReadingConnectorDecoratorBase`1.GetAllEntities(IStoredValueCollection storedValues, CancellationToken cancellationToken)
at Unify.Product.IdentityBroker.ChangeDetectionImportAllJob.ImportAllChangeProcess()
at Unify.Product.IdentityBroker.ChangeDetectionImportAllJob.RunBase()
at Unify.Framework.DefinedScopeJobAuditTrailJobDecorator.Run()
at Unify.Product.IdentityBroker.ConnectorJobExecutor.<>c__DisplayClass30_0.<Run>b__0()
at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state)",Normal

I'm trying to write a PowerShell adapter transformation. A couple of points about this:

- I want to be able to use a variable field name,

- I want to be able to search for another entity.

The use case is flattening Org Units. The feed is a classic parent-child feed and what I want is to add attributes OrgUnit1 .. OrgUnit9 to each Org Unit object in the adapter. This means I have to be able to loop through looking for parent Org Units in the $entities collection.

The following script does not work in IdB - but gives an idea about what I'm trying to do. It does work outside IdB simulating the $entity as a hashtable. If you could share some more info about what exactly $entity is I may be able to do better at getting this working outside of IdB in such as way as it will work inside too.

DOESN'T WORK:

foreach ($entity in $entities){
  $id = $entity["OrganisationUnitNumber"]
  $level = $entity["OrganisationUnitLevel"]
  $fieldname = "OrgUnit" + $level
  $entity[$fieldname]=$id
  $entity2 = $entity
  while ($level -ne "1")
  {
    $id = $entity2["SuperiorOrgUnitNumber"]
    $entity2 = $entities | where {$_["OrganisationUnitNumber"] -eq $id}
    $level = $entity2["OrganisationUnitLevel"]
    $fieldname = "OrgUnit" + $level
    $entity[$fieldname]=$id
  }
}

Hi Gents,

I'm having an unusual issue with a custom connector. When running exports, a failure is occurring. However the single failure seems to be stopping subsequent entities from exporting. I currently have export 10 configured on the MA with a batch size of 1 (<-- which is interesting)

I've confirmed that the only results.SetFailed that is hit is the one in the UpdateEntity method. This is returned to the MA with an error of 'Other' and the actual exception is NOT included. After that point, no more entities are processed by the connector, and these show up as a 'cd-error' on the MA.

Nothing significant is noted in either the IDB or Event Logs.

Environment Details:

Running IDB v5.1.0 Revision #0

Patch: Unify.IdentityBroker.ChangeLog.Repository.Sql.dll

Unify.IdentityBroker.FIMAdapter

After a recent production incident where MIM kept presenting the same watermark to IDB (5.1) on delta imports there may be an opportunity for Identity Broker to handle the watermark storage in a better way that works around this MIM issue.

From talking the Curtis he mentioned that this issue has been seen with other clients, and the only workaround is to either re-create the MA or run a full import which in large environments may not be practical. Acknowledge that this is 100% a MIM issue, but could be a plus for the IDB if it can provide a workaround to such an issue that can have a big impact on large environments.

There are a few options that I could see:

- store the watermark in the MaData directory for the MA and use that instead

- store the watermark in the MaData directory for the MA and build some smarts around that watermark in combination with the MIM provided watermark.

It could be possible done by providing an option in the ECMA2 MA to enable/disable such enhanced functionality.

Using

• IdB v5.0.5 Revision #0
  Plugins
• Microsoft Active Directory 5.0.1.2
• Microsoft Azure AD Connector 5.0.1.5

The following was written this morning to the PROD IdB logs (verbose mode):

20161213,03:00:14,UNIFY Identity Broker,Service Engine,Warning,"An error occurred whilst coordinating the plug-in engine.  The error was:

System.BadImageFormatException: Could not load file or assembly 'file:///E:\Program Files\UNIFY Solutions\Identity Broker\Services\Unify.Service.Connect32.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'file:///E:\Program Files\UNIFY Solutions\Identity Broker\Services\Unify.Service.Connect32.exe'
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at Unify.Framework.ExtensibilityPlugInDictionary`4.InitializeAssemblyAttributeDefinition(String assemblyLocation)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
",Verbose

Multiple occurrences of this issue in the 24 hour period just completed (log file just rolled over).

See corresponding JIRA issue QBE-65 for log file attachment.

Over the last couple of weeks troubleshooting a separate issue, the customer has been reporting that some users hadn't been assigned licenses. In some cases this was due to accounts in error, but in others it has turned out to be that the delta imports from the corresponding IdentityBroker adapter (run on change detection by Event Broker) have not included changes that they should have. Such changes are only surfaced to MIM after a MIM MA full import (delta sync) is subsequently run.

To mitigate this problem, a twice-daily full import/delta sync operation across both IdB adapters is being performed. Over the last 4 days since this has been in place, a number of changes continue to be surfaced in the full import some 10 minutes after the last delta import. The latest of these FI runs which returned 5 changes was run at 7:07 am on Saturday 3rd December - at a time when there should be no business activity happening in any geographic region for QBE.

Investigations into SQL queries such as the following identified identities where a MODIFY change entry was present without a corresponding INSERT:

SELECT *  FROM [Unify.IdentityBroker50].[dbo].[ChangeLog]
WHERE TargetDistinguishedName = 'CN=bob,OU=container,DC=IdentityBroker' 

Filing this against the O365 connector because it happened to be for the related adapter - but it is likely this is a generic problem unrelated to a specific connector (i.e. am seeing FI steps return records consistently for both AD and AAD-based adapters)

Re-opened issue QBE-51 previously raised for this issue.

When viewing the VERBOSE logs today via the console, and clicking NEXT, the following exception was raised:

The logs are also attached from the time of the error here: Log file archive

QBE reported this week that they are continuing to have long periods (several hours) where licenses are not being assigned, and are having to manually restart the IdB service multiple times during the day (the service is already being restarted each night at 4 am). The timeout error continues to be reported in the logs

See JIRA ticket QBE-59 for more details.

QBE reported an ma-extension-error export failure for 702 O365 license updates this morning, but on later inspection the errors appeared to resolve themselves. However on further inspection the Application Event Log revealed corresponding Index was out of range exception within the Identity Broker for Office Enterprise 5.0.1.5 connector logic.

Refer to QBE JIRA ticket QBE-64