|
Tutorials > Solution Designer > Workflow > Workflow Customization in Therefore™ Online > Azure Functions Hosted by the User Troubleshooting |
Scroll |
How does the 'Call Function' feature work?
A basic understanding of how the feature works is key to troubleshooting problems. The following diagram illustrates how the different components work together.
When the “Call Function” task is executed in the Workflow Engine, a HTTPS POST request is sent to the function. If the call was successful, the called function will be executed and most likely call the Therefore™ Server using the Web API to retrieve documents, index data or other additional information required for its purpose.
The called function can be an Azure function, a Web Service, or any executable that can react to HTTPS POST requests. However, it is required that the called function returns a JSON object that contains “TheError” string and either “TheRoutingDone” bool or “TheRetryAfterMin” integer. If a function was developed by Therefore™, it can be hosted in the Therefore™ Online Azure subscription.
For security reasons, functions developed by customers need to run on their Azure subscription, or on their infrastructure.
As shown in the diagram, all the connections between Therefore™ and the called function are just HTTPS POST requests and (Web) API calls. No customer code is directly executed by the server service, nor is any customer code run inside the Therefore™ Online environment. All permission checks apply as usual when making Web API calls. The access token provided with the HTTPS request is limited to the current workflow instance only. Because of this architecture, the workflow customization is secure to be used in Therefore™ Online.
|
|---|
How are error messages reported?
All error messages that occur should be reported to the workflow history.
As shown in the architecture diagram, Therefore™ is only sending a HTTPS request, the most important part (the customer code) is executed inside the called function.
If the function fails, all occurred errors should be reported back to Therefore™, so they can be logged to the WF history. If the function returned an error, the WF history entry will start with “The called function reported an error”. If the function crashes due to an unhandled exception or just does not return the information, there is nothing Therefore™ can log. If a function just returns a JSON object with an empty “TheError” string and “TheRoutingDone” bool set to false, it is already considered a success, as the HTTPS call worked and no error was reported.
Here are a few errors listed that can occur when calling a function:
|
|---|
How does monitoring in the Azure Portal work?
Microsoft’s “Application Insights” should be configured for monitoring Azure functions. A list of recent function calls can be shown when clicking “Monitor” after selecting a function in the Azure Portal.
Function calls will be shown as ‘successful’ if no unhandled exception occurred, regardless of the result code or caught exceptions. Therefore™ treats this similarly – if an exception was caught, it should be reported with status code 200, plus the exception information in “TheError” return string.
If an unhandled exception occurred, nothing can be returned to Therefore™ from the function, the Web Service will just send status code 500. In this case, no other information than status code 500 can be shown in Therefore™ and the Azure Monitoring needs to be checked for details.
The “Operation ID” can be used for querying the exceptions table for details and the stack traces. Copy the “Operation ID” and click on “Run in Application Insights” to open it in a new tab.
Paste the “Operation ID” into the query window and structure a query like this:
exceptions | where operation_Id == "OperationID" | limit 50
After clicking “Run”, exception information that belongs to the “Operation ID” should be listed.
There should be at least one row with exception information displayed.
Export all rows and send it to the developer responsible for this Azure function.
Also check the traces table for additional workflow information. If a sample was used, each function call should be logged with instance-, token- and case- or document-number.
Copy the previous query and replace “exceptions” with “traces”:
traces | where operation_Id == "OperationID" | limit 50
Include that information as well when notifying the developer.
If the function does any conversion tasks, the document should be provided as well. |
|---|
|
|---|
