Ideas
Provide more information in the log file for Provisioning Task failures
When a provisioning task fails in a Broker Plus Link due to a PowerShell error, the information written doesn't indicate which provisioning task failed, which line the error occurred on, or which entity was being processed.
It would be extremely helpful for debugging to know which provisioning task is the source of the error and which line is executing when the error occurs.
It would also be helpful to know which entity is being processed, but given that the PowerShell script loops over objects internally this information is not automatically available to the calling engine. In order to help with this I suggest adding a function which allows the PowerShell script to (optionally) indicate when it starts and finishes processing an entity, in order to allow Broker to include that information in the log entry.
i.e.
foreach ($joinedEntity in $joinedEntities)
{
# Tell Broker which entity we're working on $personNumber = $SourceEntity["PersonNumber"].Value
$username = $SourceEntity["sAMUsername"].Value
$logger.setIdentifier("Person $personNumber ($username)")
# Process the entity $isTerminated = $joinedEntity.SourceEntity["Terminated"].Value
$joinedEntity.TargetEntity["isTerminated"] = $isTerminated -eq "True"
# Tell Broker we're finished processing the entity
$logger.resetIdentifier()
}
Customer support service by UserEcho
The Provisioning Task identification should also indicate which Link it is as well.
Hi Adrian
Thanks for the suggestion. I'll add a backlog item for adding more identifying information to the error message. I'm not sure that information about the error internal to script such as line number is available to us to log. I'll include it in the backlog item to look into anyway.
Allowing a script to indicate which entity is being processed would only be useful in a limited number of scenarios, given the unlimited amount of options available when writing a PowerShell script. I would recommend performing error handling within the script and using the logger component. This gives you the freedom to log whatever debugging information you need at the time.
This looks relevant: https://stackoverflow.com/questions/51647538/how-to-read-errors-from-powershell-pipeline-in-c
The information in the error stream could well include details of which powershell script line (and calling stack if appropriate) triggered the error.
"Allowing a script to indicate which entity is being processed would only be useful in a limited number of scenarios"
All the provisioning and synchronisation tasks I've seen iterate over $joinedEntities as their primary function, so the facility would be useful in most scenarios, to assist with identifying data and PowerShell code problems. Could you comment further on this - what is the intended purpose of these Tasks, if not to process entities?
If you'd prefer each of the aspects of my ideas to be in separate tickets (so none get missed) then please let me know.
Provisioning tasks certainly can iterate over entities, however my point was that script writers are not limited to just that. An action may be performed as part of a provisioning task script that isn't directly related to specific entities, or related to a group of the entities, or not related to the entities at all.
When I said "limited number of scenarios" I was referring to the range of what is possible, which the logger component is designed to facilitate, rather than how common a scenario is.