Analyzing the Workflow Issue [ENT 21.3 OG]
Due to the workflow displaying an issue, one must first attempt to analyze the problem.
The Workflow Monitor should display the abstract Uri:
The SourcePlatformUri describes a file with the Id FILE-VX-29 on a storage of with the following Guid, "8513f348-71dd-cb30-aa44-f6f7f8fe2cf7". This is a direct reference to the storage configured as a watchfolder in ConfigPortal.
The Id for the video is created by the object management and the Guid should be the same as you see in the actual storage definition in ConfigPortal.
The TargetPlatformUri is not depicted as one would expect. The TargetPlatformUri, XXXX, is describing an item instead of a storage. If it would be describing a storage this should be represented in similar fashion to the SourcePlatformUri and contain a storage Guid of the defined target storage for the watchfolder Use Case.
In addition to analyzing the references, the user should also check log information regarding the workflow. VidiFlow offers users the possibility of clicking a particular element in the Workflow Monitor and under the Properties menu click on the "Log" option.
Selecting the element marked in red, MoveFileVidipspine in the workflow monitor will then offer a direct log link referencing that element. Clicking on the link will redirect the user to VidiFlow's Logs Monitor.
The Kibana Log Monitor will open up with a preselected correlationId as the defining filter. This correlationId filters for all log messages that are related to this workflow and all its involved components.
As we are looking for an error we can add a search filter "*error" and will get the result as depicted in the image below. Users will immediately notice that the corresponding log message has been marked as an error message, "Error while processing the task…".
For a detailed explanation on how to search and create searches in Kibana in a VidiFlow context, please view the Logs Monitor section.
The error message can be expanded and as a result display more details with regards to the error. In this case
"One or more errors occurred. ---> System.ArgumentException: Cannot resolve an empty storage guid, please specify a nonempty guid."
This particular message offers an explanation as to the source of the error. The message hints at the fact that an invalid abstract Uri was used to specify the target storage.
So where does the value "pf://platform/item/ITEM-VX-88/" for TargetPlatformUri come from? The watchfolder should pass the storage of the configured target storage here.
Going back to the Workflow Monitor. When selecting a single task one can also see the parameter names and values of that task in addition to the global workflow parameters.
Selecting the RegisterItemTask will display this task's output parameter, called "TargetPlatformUri". This is the cause of the actual error.
This is due to the parameter handling in the Camunda workflow engine, which serves as the basis for VidiFlow's workflow Engine.
- All input and output parameters of a task are actually local parameters of that task
- There is no problem if there are several tasks with local parameters that have same names, because they can still have different values in each local scope
- However global workflow parameters are handled differently in Camunda.
- If a global workflow parameter has the same name as a local output variable of task, Camunda assigns all values assigned to the output parameter with same to the global parameter with same name.
In our example, the global workflow parameter TargetPlatfromUri originally gets the target storage as value from the watchfolder. However, the RegisterItem task that is currently the first task in our workflow, overwrites its value when it actually writes the created item Id of its newly registered item to its "virtual" local parameter by the same name.
What we can do now is to save the original value of TargetPlatfromUri into another global parameter with different name, before the RegisterItem task is triggered.