Identity Broker Forum
Welcome to the community forum for Identity Broker.
Browse the knowledge base, ask questions directly to the product group, or leverage the community to get answers. Leave ideas for new features and vote for the features or bug fixes you want most.
Time Offset Flag didn't re-evaluate when date threshold was passed
I have the following Time Offset Flag adapter transformation configured:
For the problematical entity the EndTimestampUTC field is "4/22/2021 12:00:00 PM" (i.e. midnight at the start of April 23rd in my customer's timezone - NZ), so the corresponding UTC timestamp for the threshold comparison should be "5/7/2021 12:00:00 PM" (i.e. midnight at the start of May 8th in NZ timezone). EndTimestampUTC was changed to that value on May 7 (i.e. before UTC 5/7/2021 12:00:00 PM) but even though today is now May 10th the PostEndPlus14 field hasn't been re-evaluated to "Yes" as I would have expected (i.e. transition from the ">" case to the "<" case).
To allow a better chance to debug I have not run a Generate Changes on the adapter yet.
How soon will temporal transformations (e.g. Time Offset) be re-evaluated after the current date and time changes?
How soon will temporal transformations (e.g. Time Offset) be re-evaluated after the current date and time changes?
Return a more helpful error when an adapter accessed via ODATA is not enabled
When an non-enabled adapter is queried via ODATA the endpoint returns a 404 error. A different error with some descriptive text would make it easier to work out what has gone wrong.
PowerShell connector operation timeout
Add a feature to allow a timeout to be specified for a PowerShell connector operation (Import All, etc). When the timeout expires, forcibly kill the PowerShell operation and log an error.
This came up because a connector hung for ten days in a UNIFYConnect environment until I noticed. All of the other connectors in the same connector exclusion group were blocked from running as well. I suggest a default timeout of one hour for most operations and 10 minutes for Import Changes.
Add support for non-CSV connector types to the Test Harness plugin
Add support for non-CSV connector types to the Test Harness plugin.
This would help address problems relating to multivalued fields with commas in values.
Entity not updating after Foreign Multivalue Group relationship connector entity change
Adapter "AD Groups" has a FMG transform to connector "AD Entitlement Control Groups". When an existing entity in that connector updated (to add a second value to the "member" multivalued attribute) the FMG did not re-evaluate on the adapter. Running an Import All on AD Entitlement Control Groups did not update the AD Group adapter entity, and neither did running an Import All on the AD Groups adapter's base connector. The FMG field was only updated when I ran Generate Changes on the AD Groups adapter directly.
Access to source entity fields for target entities returned by CheckFieldUniqueness
When using the CheckFieldUniqueness component to ensure target entity field uniqueness I would like to use source entity field values in order to calculate candidate values for the unique field. I'm only aware of a way to access target entity field values.
Is there a way to access the source entities for a target entity in this scenario?
Otherwise, please change this ticket to an Idea to have the ability to do so.
I see. You could just mapping the required values to to fields on the target entities, but assuming you don't want to do that you should process the $joinedEntities collection into a HashTable keyed on the target entities. For example:
$entityMap = @{};
foreach ($joinedEntity in $joinedEntities)
{
$entityMap[$joinedEntity.TargetEntity] = $joinedEntity.SourceEntity;
}
You'll then be able to use the target entities returned by CheckFieldUniqueness to lookup the corresponding source entity efficiently.
Time Offset Flag description in UNIFYBroker doesn't match the implementation or the voice documentation
On the Edit Timeoffset Flag page in the UNIFYBroker UI, the description says:
In particular, "The target value is populated based on whether the current time is less than, equal to or greater than the offset value".
The Voice documentation (https://voice.unifysolutions.net/en/knowledge-bases/7/articles/2888-time-offset-flag-transformation) says:
An actual configuration appears like this in the UI:
When this transform was evaluated on 15/12/2020 for a value of StartDate="03/Feb/2020" the value to which PreStart was set was "Yes".
This matches the UI configuration, and the Voice documentation (i.e. source time compared to NOW - with the source time offset implied). However, it does not match the description in the "Edit Timeoffset Flag" UI (i.e. NOW compared to the offset value - with "offset value" presumably meaning "source time plus offset"). The "Edit Timeoffset Flag" UI description is reversed compared to those others and therefore misleading.
Allow $logger component to specify module and submodule fields
There is no documented way to set the third and fourth fields (which I will call 'module' and 'submodule') of each UNIFYBroker log entry when calling the $logger component. It would be nice to be able to set them to more informative values, rather than always having them as 'UNIFYBroker' and 'PowerShellTask' respectively.
Hi Adrian,
The $logger component is designed to be a simple wrapper around the logging mechanism. For more complex log messages, use the $messageService variable.
There's some extension methods provided for the next level of logging. You can find more information on those here:
Class NotificationEnumerableExtensions (unifysolutions.net)
Otherwise, you can use the underlying NotificationMessageService to notify listeners of a particular message. In this case, the product loggers will be listening on ILogEntryNotification: Class LogEntryNotification (unifysolutions.net)
The tricky thing with crafting one of these will be building the branding object, (for a BrandedLogEntry). Technically this would allow you to change both the 'module' and 'submodule' components.
For ease of use, i'd recommend just using the NotificationEnumerableExtensions to log - which still use the underlying product for the third field but allow you to define the fourth field.
As a side note, for some reason the $messageService variable isn't actually hooked up for the Plus components, but is hooked up for the Powershell connector and transformations.
Next run times don't look right for newly added connector schedules
It's ~9:30am and I just added and enabled an Import All and Import Changes schedule to a connector. The Import All I set to run at 12:55:57am, and the Import Changes every 1 minute. The following appeared, which doesn't look right - 1am isn't an hour away, and one minute is not 10 hours away:
Hi Adrian,
The scheduled times are displayed in the local time of the machine. In this case, the containers are running on UTC. So with the UTC time (at time of screenshot) being 11pm on 30 November, that looks accurate.
Customer support service by UserEcho
