In the previous post of the series, we’ve covered the different built-in observability features that are available in Logic Apps Standard and how many of them are part of the traces sent to Application Insights. In this post, we’ll discuss how these features can be implemented in a sample scenario. The series is structured as outlined below:
The code of the solution shown in this post is available on GitHub.
To demonstrate how to leverage these observability features in Logic Apps, I’ll use a very common integration scenario: the publishing and consumption of user updated events. Think of an HR or CRM system pushing user updated events via webhooks for downstream systems to consume.
To better illustrate the scenario, let’s describe the different components of the end-to-end solution.
Figure 1. Sample scenario components
The figure below shows the Logic App publisher workflow.
Figure 2. Publisher workflow
The workflow’s steps are described as follows:
InterfaceId
is tracked using trackedProperties
.The code behind the workflow can be explored on GitHub.
The observability practices implemented in this workflow are detailed below and follow the practices described in the previous post.
Figure 3. Enabling Application Insights integration
Figure 4. Configuring the custom tracking id property
"triggers": {
"manual": {
"correlation": {
"clientTrackingId": "@{coalesce(triggerBody()?['id'], guid())}"
},
"inputs": {},
"kind": "Http",
"type": "Request"
}
}
Code snippet 1. Configuring clientTrackingId
in a HTTP trigger
Compose
action are being used to log an interface identifier. The code behind this action is shown below."Trace_workflow_metadata": {
"inputs": {
"InterfaceId": "USER.SVC01.P01v1"
},
"runAfter": {},
"trackedProperties": {
"InterfaceId": "@{outputs('Trace_workflow_metadata')?['InterfaceId']}"
},
"type": "Compose"
}
Code snippet 2. Configuring trackedProrperties
in a compose
action
RunAfter
setting is being used for error handling. The code view of an action implementing runAfter
is included below."Return_400_BadRequest_response": {
"inputs": {
"body": {
"ActivityId": "@{workflow().run.name}",
"Message": "Bad request. Invalid message.",
"StatusCode": 400
},
"statusCode": 400
},
"kind": "http",
"runAfter": {
"Parse_Request_Payload": [
"Failed"
]
},
"type": "Response"
}
Code snippet 3. Configuring error handling using runAfter
terminate
action with failed
status is used adding a custom error code and error message. The code view of a terminate
action used in this workflow is shown below."Terminate_as_Failed_(PublisherReceiptFailed_InvalidMessage)": {
"inputs": {
"runError": {
"code": "PublisherReceiptFailed_InvalidMessage",
"message": "Invalid HTTP request payload received in publisher interface."
},
"runStatus": "Failed"
},
"runAfter": {
"Return_400_BadRequest_response": [
"Succeeded"
]
},
"type": "Terminate"
}
Code snippet 4. Using a terminate
action with custom error code and error message
The figure below shows the Logic App subscriber workflow.
Figure 5. Subscriber workflow
The workflow steps are described as follows.
InterfaceId
is tracked using trackedProperties
.The code behind the workflow can be explored on GitHub.
The observability practices implemented in this workflow are detailed below and follow the practices described in the previous post.
"triggers": {
"When_a_message_is_received_in_a_queue_(peek-lock)": {
"correlation": {
"clientTrackingId": "@{if(empty(triggerBody()), guid(), triggerBody()['Properties']?['ClientTrackingId'])}"
},
"inputs": {
"host": {
"connection": {
"referenceName": "servicebus"
}
},
"method": "get",
"path": "/@{encodeURIComponent(encodeURIComponent('user-updated'))}/messages/head/peek",
"queries": {
"queueType": "Main"
}
},
"recurrence": {
"frequency": "Second",
"interval": 10
},
"type": "ApiConnection"
}
}
Code snippet 5. Configuring clientTrackingId
for a Service Bus trigger
trackedProperties
in a compose
action are used to log an interface identifier. The code behind this action is shown below."Trace_workflow_metadata": {
"inputs": {
"InterfaceId": "USER.SVC01.S01v1"
},
"runAfter": {},
"trackedProperties": {
"InterfaceId": "@{outputs('Trace_workflow_metadata')?['InterfaceId']}"
},
"type": "Compose"
}
Code snippet 6. Configuring trackedProperties
in a compose
action
runAfter
setting is used for error handling.terminate
action with failed
status is used with a custom error code and error message.In this post, I’ve described a sample implementation of a publish-subscribe scenario using Logic App Standard and how the different observability practices described previously can be implemented in the corresponding workflows. In the next and final post of the series, I’ll describe how the different traces that result from these practices can be queried and analysed using Kusto Query Language.
Cross-posted on Paco's blog
Follow Paco on @pacodelacruz