AXForum  
Вернуться   AXForum > Microsoft Dynamics CRM > Dynamics CRM: Blogs
CRM
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.02.2021, 19:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
sertandev: Better Logic Apps error handling with consolidated error reports
Источник: https://devblog.sertanyaman.com/2021...error-reports/
==============

With the correct use of Logic App “Scopes”, you can add try-catch style error handling functionality to your Logic Apps and in your Catch scope you can retrieve the fault details for failing blocks using “result(“”)” function (See my sample logic app template given further in the document).

However, fetching the actual error message from that result outputs is quite a challenge since there is unfortunately no LA standards on where in the output body this message exists and nearly every type of block reports their error message on different parts of the output document. Even the JSON tag name for the error message is not a standard and varies per blocks.

So, if we catch an error in the runtime of our Logic App, how to fetch the actual error messages for processing later?

We have tools like Application Insights to track errors on Logic Apps on administrator level and see all the error messages. However you may be asked to do something with these error messages within your Logic App as well, like returning it to caller with a HTTP response, perhaps return it for displaying to end user in a GUI, or logging it to somewhere else than Application Insights, like storing error on a database table or sending errors as e-mails with certain formats. In that case you need to find the error messages from different body locations in different block results, which may be quite a pain.

Consolidated error reports Azure Function

I was required to do exactly this and created an open source Azure Function to find error messages from different blocks and combine them in an array of standardized JSON error objects as a response. The function is available in my GitHub repository :

https://github.com/sertanyaman/conso...orts-logicapps

In current version the returning error object contains following fields:

FieldDescriptionCodeCode given for the exception (ex. 400,500 for http exceptions)BlockNameName of the logic app action which gives this exceptionMessageException messageStackTraceStack trace (if applicable)SourceException creating source (Exception class names in Azure function exceptions)ClientTrackingIdLogic apps tracking IDStartTimeLogic apps trigger execution datetimeThe result from the Azure function looks like this :

To be able to use the function, you need to combine the results of different scopes (using LA union() function on result(“”) outputs) and filter on the status field “Failed”, then give this as an input to the function. A sample Logic App template using this function is also available in my GitHub folder (You need to publish the function first) :

https://github.com/sertanyaman/conso...ppErrorHandler

As a best practice, always set the scopes close to your possibly failing LA blocks and combine these lower level scopes (with union) as input for the function. If the failed block is in another scope within the scope you use in result(), or if it is in one of the for-each or if-else blocks within the scope, things get more complicated and you only get the dreaded “ActionFailed. An action failed. No dependent actions succeeded.” logic app error.

Let’s also mention that it currently does not support the whole collection of LA blocks in the world. However it supports many standard LA blocks, like errors from C# AZ functions V1,2,3 (Serialized-non-serialized format), OData errors and many LA standard actions having an error tag in their output. It is also possible to add new ones to the code and I will update it as I encounter new block types. If the tag containing the error message not found in the result document, it falls back to returning whole output body in the Message field. If output body also does not exists (there are blocks like that), it returns a pretty standard “An internal error has occurred, unable to process the request” message.

Hope this function will be usefaul for you too,

GitHub repo :

https://github.com/sertanyaman/conso...orts-logicapps





Источник: https://devblog.sertanyaman.com/2021...error-reports/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
powerobjects: Azure Logic Apps and Dynamics 365 Blog bot Dynamics CRM: Blogs 0 12.09.2018 00:15
survivingcrm: Exploring CDS for Apps Platform Licensing (PowerApps) Blog bot Dynamics CRM: Blogs 0 10.05.2018 23:12
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 16:31.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.