Time Archives - Business Intelligence Info

Tag Archives: Time

Monitoring the Power Platform: Power Automate – Run Time Part 3: Implementing a Monitoring Strategy

June 27, 2020 Microsoft Dynamics CRM

Summary

Microsoft Power Automate is a service allowing makers to create business processes, orchestrations and workflows to help achieve common and even complex business requirements. Within the Power Platform, Power Automate represents one of the most important pillars of the platform. It provides a no to low code solution to process automation. From sending push notifications to mobile devices, to complex robotic process automation flows, Power Automate can be used in virtually any workload.

The goal of this article is to describe how to implement a monitoring strategy for both Power Automate and the Logic App services. We will explore how to create custom identifiers to be used for tracking run time actions and flow history. We will discuss using the Azure Log Analytics Data Collector connector. The article will also show how to build a delivery mechanism to Azure Application Insights from Power Automate Flow. Finally, we wrap with considerations for using Azure Log Analytics and Azure Application Insights.

Adding Custom Identifiers

Power Automate Flows generate tracking identifiers for each individual flow and specific action within a flow run. For each workflow, triggers and action, these auto generated identifiers are included and available as part of the various objects documented in Part 1: Triggers, Workflows and Actions. These typically are very helpful, specifically the workflow run name, when reviewing previous run information via the UI or PowerShell.

We’ve also seen, in Part 2: Tracked Properties and Error Handling, how connectors themselves can often provide identifiers in form of header properties that can be tracked. These returned properties from the connector response are vital when troubleshooting and supporting standard and especially custom connectors.

That said, there will come a time when you may need to generate or provide an identifier yourself. Luckily, Power Automate Flow provides the ability to do both, by passing in a tracking identifier or generating one which can be used across actions or even other flows as the calling flow. This allows makers to set the expectation that the flow will return a pre determined identifier which can then be used across other workloads.

Tracked Properties

Before we get into identifiers, please take a moment to review the Tracked Properties section in Part 2: Tracked Properties and Error Handling to familiarize yourself with attaching data to actions.

Utilizing a system provided Correlation Id

Power Automate includes its own correlation identifiers as referenced in the Get-FlowRun cmdlet as part of the ClientTrackingId. This identifier can be obtained in the flow itself by use of the outputs object. Consider using this or a custom tracking identifier when working with external integrations to assist with application and workload monitoring. By implementing this early, the beginnings of an application map can appear when working with Azure Application Insights as shown below.

AUTHOR NOTE: CLICK ON EACH IMAGE TO EXPAND FOR DETAIL

4382.pastedimage1593183235379v1 Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

Using the guid() function, we can generate a identifier based on various formats that can be used as the ClientTrackingId or passed to other connector actions such as Common Data Service creates or updates or even custom connectors as detailed below.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

Adding a custom Tracking Id

The Custom Tracking Id, part of the trigger, allows for the static of dynamic input of an identifier that can be passed in or set from the trigger and added to the response. This identifier can also be used across child flows to represent the calling or parent flow.

As the image below shows, we can use the “Custom Tracking Id” field to set a static or dynamic value. This example shows setting the custom tracking id from a property in the body of a HTTP request called correlatonid.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

An added bonus to using the trigger in this fashion is that we now can add conditions that work as a gate keeper to our flow. In this scenario we can strictly enforce that if a correlating identifier is not provided to the flow, the flow will not run and return a message expecting the identifier. This design is very important to ensure visibility and supportability, and as such needs to be included as a first step, as we include more and more integrations into our workloads.

In the example below we have a HTTP request and response Power Automate flow. In the request a Tracking Id “PowerAutomateArticleExampleId” has been provided.

In the response, captured in Fiddler or Postman, we can see the response header now includes our custom tracking Id represented by “x-ms-client-tracking-id”.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

This technique can be propagated down to Child Flows as well as shown below. As with the parent, the “x-ms-client-tracking-id” is now included within the Child Flow. This allows the Child Flow to use the same tracking Id for any actions or tracked property.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

Finally, an added benefit is that this same custom tracking identifier will be available as part of the “Get-FlowRun” cmdlet covered in Part 4: Reviewing Run History with Get-FlowRun.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

The Log Analytics Connector

One approach that can help deliver event data to Azure Monitor is to utilize the Log Analytics Data Collector connector. Utilizing the Azure Monitor HTTP Data Collector API, we can ingest data in virtually any structure using a JSON formatted string. Since every object in our Power Automate Flow is formatted in JSON we can send any item we want, from scopes to actions to the entire workflow.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

Creating Custom Tables

Below is an image showing custom tables created by using the Log Analytics Data Collector connection action.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

Here are the actions that created these tables starting with the PowerAutomateFlow custom table.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

Here is the action for PowerAutomateActions:

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

As shown, one of the benefits of Log Analytics is the ability to add custom tables to the workspace. When these custom tables are created, they can be added to by passing in additional properties. For instance, in the image I have a table for Power Automate Actions that was created by passing an action object in. Starting with a simple initialize variable I may only have a couple of fields created in my new table. However by passing in a more robust output from an action, like the Common Data Service, I begin to grow my table exponentially.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

Here is an example gif showing using the workflow and action object. The workflow object is well defined however actions can become cumbersome. In this example we are splitting these into two separate tables.

NOTE: Consider using custom tables for specific actions.

1665.pastedimage1593183235382v13 Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

This approach provides extreme flexibility but does come with a cost. Data can quickly become fragmented, null saturation can become unmanageable and even fields that we would often use for identifying can become obscure. We quickly can render our logs useless working this way and should provide some limits to what can be provided. Without meaningful data, what value are the logs we’re capturing?

Thoughts on Controlling the Collector

I like the approach shown due to the flexibility of the endpoint and the native integration it has with Azure Logic Apps. Creating custom tables and allowing data ingress in any shape or form does have benefit. Also, by using the Log Analytics Connector, all Azure Logic App and Power Automate Flow run time data (tracked properties, action results, etc) can be centralized. This allows for ease of use reporting and monitoring. That said, we need to build in enforceable and stringent rules to what our tables will accept to ensure quality as we move ahead.

The Case for Application Insights

Azure Application Insights, as mentioned in previous articles, is an application performance monitoring platform. Power Automate, at the time of this writing, does not have a native integration or feature to push events to Application Insights. However, as with Log Analytics, there is an HTTP endpoint that can be used to send messages to Application Insights. How that HTTP endpoint is invoked is up to the enterprise. HTTP requests can be issued directly from Power Automate Flows. Custom connectors can be created to help delivery of messaging.

The next section will go into building a direct request to Azure Application Insights. This is similar to the approach I’ve documented in the past for sending messages from Dynamics 365 Plug-ins.

Utilizing the Application Insights REST API directly

To achieve this we will send a POST message to the Application Insights endpoint with the definition of the specific event we want to capture. This endpoint can accept one or multiple messages so it can be used at the end of a Power Automate flow run or really anywhere. Combining the messages and sending at the end would follow a similar approach as with the Azure Log Analytics Data Collector action. As long as the action is ensured to run and we have our contracts correctly defined, we can rely on the API to deliver our messages. One of the benefits of the Application Insights endpoint is it does allow any well defined message payload and will report back the number of accepted and failed messages.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

The trigger I’m using here is the Power Apps trigger which allow for use of this flow as a child flow. Remember, to use this flow in this manner utilizing Child Flows, the flow must be solution aware.

Building the Message Body

Azure Application Insights, like Azure Log Analytics, can accept JSON serialized requests and store within tables within the log store. Unlike Log Analytics, specifically the Data Collector, is that Application Insights expects a well formed structured message. Each message contains these minimal properties: time (represents timestamp), iKey (Instrumentation Key), name (the name of the table/message) and data (the message payload). A reference to building this contact can be found here.

The data property is specific to each message type and will include a baseType and baseData property within. A good reference for finding out more can be found on the ApplicationInsights-JS Interfaces folder. For each message type, be it exceptions, custom events, traces, etc., there are common and explicit properties. Consider the below image.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

The image above shows how to take the contract for a specific table and inject variables which will show up in Application Insights. In this example I’m only using the customEvents table but this can easily be extended for all tables within Application Insights.

Most tables in Application Insights include a customDimensions and customMeasurements property bag which I would recommend passing contextual data from the flow. In the example above, the properties property within baseData allow for a json object to be passed in. The image above shows the trigger function but this could also be the workflow object, or maybe a particular action that failed. The below image shows using the action object output with the Exception message in Azure Application Insights.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

All tables include user and session data points which can be used to help facilitate out of the box capabilities in Application Insights such as the application map mentioned above.

Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

Utilizing Azure Functions and Custom Connectors

Azure Functions provide a great way to build micro services including ones to help surface run time data from Power Automate Flow or Model Driven Application Plug-in tracing. Azure Functions can be written using .NET Core and included is native integration with Azure Application Insights. Alternatively, we can import the Azure Application Insights SDK to provide a streamlined approach to delivering messages. The article Monitoring the Power Platform: Custom Connectors – Building an Application Insights Connector covers building both an Azure Function and Custom Connector to realize this approach.

Choosing between Log Analytics and Application Insights

The information above has provided mechanisms showing how to deliver events to Azure Monitor utilizing the Azure Log Analytics Data Collector or the Azure Application Insights REST API. Choosing one of the other requires considerations into the features and benefits and maybe more importantly the limitations of both. For an overview of each please review the Monitoring the Power Platform: Introduction and Index article.

6076.pastedimage1593183235383v18 Monitoring the Power Platform: Power Automate Run Time Part 3: Implementing a Monitoring Strategy

As we progress through the Monitoring the Power Platform series, we will dive deeper into these considerations and why to choose one over the other based on requirements. Ultimately the log store for Azure Application Insights is available in Azure Log Analytics but the features provided by Azure Application Insights allow for deep “insights” into scenarios we are interested in.

Next Steps

In this article we have discussed using custom identifiers to help track flow history and specifically group parent and child flows together. We have examined how we can use trigger conditions to enforce the use of custom identifiers. From there we reviewed the Azure Log Analytics Data Collector connector and how to setup and send messages to custom tables. After that, we went into building and sending Azure Application Insights messages directly in Power Automate flow.

In previous articles, we discussed how to evaluate workflows, triggers and run functions to help deliver insights. In the following articles covering Microsoft Power Automate Flow run time, we will discuss pushing events to Application Insights and reviewing previous flow runs for monitoring and governance.

If you are interested in learning more about specialized guidance and training for monitoring or other areas of the Power Platform, which includes a monitoring workshop, please contact your Technical Account Manager or Microsoft representative for further details.

Your feedback is extremely valuable so please leave a comment below and I’ll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, please go here to submit a new issue.

Index

Monitoring the Power Platform: Introduction and Index

Let’s block ads! (Why?)

Dynamics 365 Customer Engagement in the Field

Time to Beef Up Your Algorithms

June 19, 2020 CRM News and Info

I had a good conversation with a smart guy in Marin County over the weekend about the next normal and one thing he said seemed to be aimed at the heart of CRM. This impressed me because Kevin is not a CRM guy, though he started and successfully ran a couple of businesses for decades.

Kevin’s contention is that the virus is removing a lot of spontaneity from society. After all, we’re a culture founded by people who picked up stakes and moved west — and sudden moves are something we know.

Before the virus we shopped impulsively, made decisions instinctively, and acted spontaneously; long-term planning is not the strong suit of many citizens, though when we want to buckle down, we can go to the moon. Daniel Kahneman, one of the fathers of behavioral economics totally gets this and explains it in his books.

The Role of CRM

So, what about CRM in all this? Its main approaches currently involve capturing customer data in support of decisioning tools that do things like suggest the next best product or idea to support deal making. But in the near present (a term my friend Steve G. likes) our algorithms, which are basically tuned to accuracy, might also need to be more tuned to precision.

What’s the difference?

Accuracy means getting the right answer and precision is about getting the right answer, time after time. In a CRM situation an algorithm that gets the right answer is accurate and nice (we got the deal!), but if the business process supported by CRM has a lot of returns or unhappy customers, it’s not very precise.

The cost of imprecision is returns, which have a cost to bear — or lost customers, which have another.

So now here we are, mostly at home and just beginning the process of reopening. We’ve gotten by on a steady diet of Amazon deliveries, food drop-offs and curbside service. The really brave have also done self-haircuts. Most of that has gone rather well (haircuts perhaps excluded), though delivery costs are high and some things are just not returnable.

But imagine that the next normal features a lot more transactions through the screen. We’ve only been at this for a little while, so most people have not let their secret shoppers out. This means we haven’t really tested the limits of shopping for clothing. Getting things that don’t fit properly and require assistance to get right is a problem.

Better Algorithms for Fewer Returns

There are a few sites that already use the cameras on our phones to take our measurements and produce bespoke things that just have to be perfect (MTailor is one example). I suspect we’re going to see many more sites like this and not just for clothing. At issue, the specialty retailer is going to become a software vendor or the few that exist are going to be absorbed into bigger CRM solutions.

This in turn might lead to an increasing number of specialty processes mediated by even better algorithms — all in the service of making online shopping “return proof.” That’s where spontaneity comes in. The time might be approaching when we don’t shop with the expectation that half of what we order can go back once we’ve tried it on or examined it with some accessories we already have.

I suspect this will happen most with non-luxury items that don’t cost a lot and therefore don’t have a big profit margin to support the overhead of the occasional return. Vendors of luxury items will continue to offer that kind of service because service is the heart of luxury.

But for the quotidian purchase, I’m betting that we see tighter algorithms and more varied data collection to support them. Who knows? We might even see a personal phone app that captures and secures all of the data we really hate to share — like the size of our thighs, our weight, or our most recent optical prescription — the things we share on a need-to-know basis before we are allowed to make a purchase than can’t be returned.

We’ll have the virus to thank and in 20 years all of this will be great fodder for a cocktail party.

The opinions expressed in this article are those of the author and do not necessarily reflect the views of ECT News Network.

Denis%20Pombriant Time to Beef Up Your Algorithms
Denis Pombriant is a well-known CRM industry analyst, strategist, writer and speaker. His new book, You Can’t Buy Customer Loyalty, But You Can Earn It, is now available on Amazon. His 2015 book, Solve for the Customer, is also available there.
Email Denis.

Let’s block ads! (Why?)

CRM Buyer

Monitoring the Power Platform: Power Automate – Run Time Part 1: Triggers, Workflows and Actions

June 12, 2020 Microsoft Dynamics CRM

Summary

Microsoft Power Automate is a service allowing makers to create business processes, orchestrations and workflows to help achieve common and even complex business requirements. Within the Power Platform, Power Automate represents one of the most important pillars of the platform. It provides a no to low code solution to process automation. From sending push notifications to mobile devices, to complex robotic process automation flows, Power Automate can be used in virtually any workload.

The goal of this article is to describe how to implement a monitoring strategy for both Microsoft Power Automate and the Azure Logic App services. Every Microsoft Power Automate Flow or Azure Logic App contain functions and objects which can help designers capture and troubleshoot run time information. Within this article we will explore triggers and how they can be configured to reduce runs with conditions. From there we will go into the various workflow and run time objects that help deliver meaningful run time insights into our flows. Finally we will wrap with actions and their outputs, which can be used as determining factors for conditions or for monitoring integration responses.

Triggers

Triggers are used to fire off a Microsoft Power Automate flow. They can be triggers that are invoked, triggers that reoccur and triggers that poll for a specific event. For more information regarding different types of triggers such as poll and push triggers, please refer to the “Monitoring the Power Platform: Power Automate – Connectors, Connections and Data Loss Prevention Policies“ article.

Trigger settings consist of custom tracking identifiers, secure input and outputs, concurrency settings, schema validation and trigger conditions.

NOTE: CLICK ON AN IMAGE TO ENLARGE TO SHOW DETAIL

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

Secure Inputs and Outputs

Secure inputs and outputs can be used to hide input and output data on triggers and actions. Keep in mind important considerations, including the obfuscation of data and the impact, when using secure inputs and outputs. I’ll cover this more in the following article for reviewing run time data.

2318.pastedimage1591822760077v2 Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

Concurrency and Parallelism

The concurrency control is a feature enabling designers to handle queued runs in the Power Automate pipeline. As described in the feature description, this can’t be undone once enabled. The advantages and limitations of using concurrency and parallelism, while out of scope of this document, are well documented. For Common Data Service, the change set feature may come in handy when dealing with concurrency in loops.

Schema Validation

Schema Validation is a useful feature when dealing with triggers that handle custom inputs, such as HTTP requests. Within these requests can reside any payload with different types of serialization. To help enforce and ensure delivery of meaningful data to downstream actions, schema validation can be used.

Typically, when working with HTTP requests in Power Automate, a sample JSON payload can be provided to help describe what data needs to be provided and what format. Within this description, designers can provide a additional schema to set certain fields as required. Joe Gill‘s article “Json Schema Validation in Logic Apps and Flow“ does a great job showcasing how this feature can be used.

Schema Validation, coupled with trigger conditions, provide designers robust techniques to ensure that a Power Automate flow is triggered only when needed data is available.

Trigger Conditions

Trigger conditions are used to enforce conditional policies to ensure Power Automate flows will fire only once all conditions have been met. They can consist of trigger body or headers properties that can be used in conjunction with expressions and functions in flow.

The following image shows a trigger condition that will keep the flow from firing unless the correlationid and body fields are present in the triggerBody object.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

Trigger Object

Triggers can contain inputs, outputs, timings, keywords and statuses. Depending on the type of trigger you may or may not receive specific properties. Keep this in mind when attempting to read from the trigger object as some, such as recurrence, will not contain inputs and outputs.

The below image is the trigger for a Recurrence:

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

Here’s an example of the trigger object for Recurrence:

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

The below image is the trigger information for the Common Data Service, which unlike the Recurrence contains the Retry Policy feature:

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

Notice the host contains the specific operation id, but more important is the dataset parameter which shows which environment the trigger is listening to. In this case this represents the “(current)” environment. Additionally the correlation and client request identifiers (x-ms-correlation-request-id and x-ms-client-request-id) are shown which can help track and troubleshoot flows.

Workflow

The Power Automate run time information can be found in the workflow method which contains information about the flow, the environment, and the specific run. This object can be stored as a variable in the Power Automate flow and even can be passed as a response from the flow itself. The below image shows how the output when setting the “workflow()” function as an object.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

The Workflow Time Stamps and Tracking Identifiers

Within the root of the workflow object lies properties that can help administrators track the specific workflow run. The clientTrackingId, a tracking Id, start time and end time are displayed here. Looking into the time stamps I don’t see them lining up with the data provided for solution aware flows using the Get-FlowRun cmdlet, but more to the trigger timing. That said, Tracked Properties can help for stand alone action and/or flow duration tracking.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

The Workflow Run Object

To find out more about the specific run, you can cast the workflow().run object as a variable and view the properties. Run properties include the id, the name, and the type. This information, specifically the “name” property, can be correlated to the ClientTrackingId found in the Get-FlowRun cmdlet which we cover in the next article.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

For Azure Logic Apps, please refer to this document detailing the REST API.

The Workflow Tags Object

Additionally, the flow is further described in the tags object. The tags object contains the display name (flowDisplayName), the environment it belongs to (environmentName), if its part of the common data service (solution aware) (sharingType) and the logic app name (logicAppName).

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

The tags object is extremely important for Power Automate Flows as it stores the information needed to find a specific flow in an environment. Using this tags object, coupled with the run object properties, will allow for deeper insights and analysis.

Capturing Connection and Action Responses

One of the greatest capabilities of Microsoft Power Automate is the ability to connect systems in a no code approach allowing makers from all sorts of background to develop integrations. Most of these integration connections perform some sort of action to gather and manipulate data, invoke a process, and return some value. Each of these actions includes some output which can be read and stored for further examination natively within a Power Automate flow.

The Action and Actions Functions

To begin working with Actions responses within other actions, review the Actions function documentation. The Actions functions (both action and actions) can be used but work a bit different depending on how they are to be used.

The current action output at runtime can be read from using the action function. The function is limited to specific action types such as unsubscribe or do-until actions. They can also be added to Tracked Properties which are discussed in a following article.

To read information from previously run actions within a Power Automate flow, use the actions function. When using the actions function, the entire action object is presented. Included are shorthand functions actionBody, actionOuputs and body.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

Action Outputs

The output for a particular connector action can be read by using the expression outputs(‘<name of the action>‘). In these action outputs, specifically ones that perform an external connection, are headers, the status code and output body. The value of the variable is an expression “@outputs(‘Update_a_record’)“.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

You can see the top action is called “Update a record” and is a Common Data Service connector action.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

The image above shows a comparison of the Common Data Service Trigger against the Action. Notice how the action includes the status code as opposed to the status of succeeded that the trigger produced. This status code along with the header and body is essential to finding out the outcome of our integration.

Output Header

The output, if using a connector, will include the header properties from the response of the connector. Inside here we can find information pertaining to accepted and expected formats. Session and cookie information including correlating identifiers such as “REQ_ID” or “x-ms-service-request-id“, can also be found here to troubleshoot. For Common Data Service calls, the aforementioned identifiers and API throttle headers can be used to help shed light on potential issues.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

Output Body

The output body contains the response data from the connector request. Depending on what connector and action used, we’ll see various values. Typically, when designing Power Automate Flows, values from the output body are what are used downstream in other conditions and actions. For the Common Data Service, this could be list of records, responses from custom actions, or possibly empty.

Monitoring the Power Platform: Power Automate Run Time Part 1: Triggers, Workflows and Actions

For outputs, just like inputs, keep in mind the considerations when using the secure inputs and outputs feature.

Next Steps

In this article we have covered the beginnings of controlling and monitoring Power Automate Flow runs. Configuring triggers using Schema Validation and Conditions to reduce noisy flows were examined. Using functions such as workflow and actions to expose run time information was also discussed. This information, exposed from these functions and objects, will prove useful as we continue down the following articles for monitoring run time information in Microsoft Power Automate.

In the following articles covering Microsoft Power Automate Flow run time, we will explore tracked properties, secure input and output and how they can be used to extract and pass data between actions. We will also look at techniques for error handling. Finally we will discuss pushing events to Application Insights and reviewing previous flow runs for monitoring and governance.

Index

Monitoring the Power Platform: Introduction and Index

Let’s block ads! (Why?)

Dynamics 365 Customer Engagement in the Field

Monitoring the Power Platform: Power Automate – Run Time Part 2: Tracked Properties and Error Handling

June 11, 2020 Microsoft Dynamics CRM

Summary

Microsoft Power Automate is a service allowing makers to create business processes, orchestrations and workflows to help achieve common and even complex business requirements. Within the Power Platform, Power Automate represents one of the most important pillars of the platform. It provides a no to low code solution to process automation. From sending push notifications to mobile devices, to complex robotic process automation flows, Power Automate can be used in virtually any workload.

If you have not already reviewed Part 1 in the Power Automate Run Time series, please do so as this article is a continuation of previous installments. In this article we will discuss Tracked Properties and how they can be used across actions with a Microsoft Power Automate Flow. We will then look into handling and capturing error information within actions to help troubleshoot and report on failing actions or flows. Finally we will examine the Try, Catch, Finally pattern and result function for monitoring insights.

Action Tracked Properties

Tracked Properties are part of most actions within Power Automate. They provide the ability to add properties behind the scenes that can be referenced as part of the specific action. With tracked properties, we can set variables such as time stamps, capture trigger headers and outputs, action outputs, or even previous tracked properties from earlier actions. Expressions, such as “utcNow, outputs, actions” can be used to track what normally wouldn’t be stored in action inputs. Tracked properties are packaged within a node in the action and can easily be referenced, reducing clutter.

Action Headers Example

Consider the image below which shows capturing the status code and API throttle information for a List Records action in the Common Data Service (current environment) connector.

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

The example image below, where we are performing a ‘List records’ with the Common Data Service connector, now has a more friendly way of tracking the response code and API throttling response. This is a light weight example but should drive home the concept of how, using Tracked Properties, I can now reference the “TrackedPropertiesExample” variable which now includes outputs from a previous action.

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

NOTE: A key point here is that the action function will work for tracking current action data but not previous actions with the actions function. Attempting to do so will result in the “Tracked properties can only reference its own action’s inputs and outputs, trigger inputs and outputs and parameters.” error.

Timestamp Example

Using “utcNow()” as a tracked property for an action creates an interesting result. At first impression, we would be led to believe this may represent the start time of an action. However, when reviewing the output this function actually produces the end time exactly as if we were to reference it from the output of the action. Consider the below gif:

1122.pastedimage1591890792098v3 Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

You can see that the five second delay is showing the tracked property “FiveSecondDelay” as the same timestamp as the endTime from the output!

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

Finally, as we look to Azure Logic Apps and what may come with Microsoft Power Automate, we can see how tracked properties work with monitoring solutions. Azure Logic Apps can connect to Azure Log Analytics natively to log logic app runs. One way to extend the information stored in the log store is to use Tracked Properties.

5280.pastedimage1591890792100v5 Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

Handling and Capturing Errors in Actions

Typically Microsoft Power Automate flows will fail out if an issue occurs. Manually we can review these failures in the Power Automate Portal or with PowerShell. However inside the Power Automate flow we have the ability to track the statusCode within the actions function. Along with the Configure Run After setting we can conditionally capture any error messages and report or store for analysis.

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

Configure Run After

The Configure Run After setting allows the flow to continue if an error or timeout occurs. This can be used in conjunction with the below image showing a conditional based on status code of a previous HTTP request output body:

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

This documentation from Azure Logic Apps does a great job detailing the “run after” behavior. Each action is marked with a status of “Succeeded“, “Failed“, “Skipped” or “TimedOut“. The below image, from the Azure Logic App documentation, details how the “run after” behavior works in parallel branches.

3750.pastedimage1591890792101v8 Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

Retry Policies

Retry architectural patterns are nothing new in our continually evolving, interconnected world of dispersed systems. In Robert Daigneau’s excellent book “Service Design Patterns”, he goes into great detail discussing various patterns. One such example to handle errors when connecting and processing integration requests and responses involving retry is the Idempotent Retry pattern. (pgs 206 – 212).

In the case of Microsoft Power Automate and Azure Logic Apps, we have a feature called Retry Policy which can be beneficial when working with integrations. Based on the status code returned (408, 429, 5xx, ect), the retry action can be configured to trigger a retry based on different intervals (Default, Exponential, Fixed). The default policy is to send up to four retries scaled by 7.5 seconds.

Mock Responses

Integration actions can simulate responses, which can be helpful to troubleshoot without invoking a live system or for designing error handling.

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

These simulated responses can be used, similar to mocks, when developing custom APIs and are quite useful when building custom connectors. The response can be successful, error prone, time out prone, etc based on the scenario. A specific status code and response can be added to help troubleshoot these specific scenarios.

The image below shows setting up a failed mock response and the many different error codes.

NOTE: Depending on what connector you’re using, you may not be able to use certain error codes.

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

The below image shows mocking a Common Data Service API throttled error response:

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

This image shows mocking a Common Data Service Too Many Concurrent Requests error response:

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

Finally, the below image shows the run history and capturing the error response from the Common Data Service:

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

Throttling with Azure Logic Apps

Throttling in Azure Logic Apps has many facets and can stem from all sorts of potential areas. Connectors can be throttled, destination APIs can be throttled and depending if you’re running in an integration service environment (ISE) or not can impact that. Consider the following documentation in detail when deciding an implementation approach with Azure Logic Apps. Scenarios such as dealing with Azure Service Bus queues are thoroughly examined (e.g. using nested logic apps…this technique will work for Microsoft Power Automate as well!)

Webhook Tester Site and runtime debugging

The below reference and steps are taken from the Azure Logic Apps document “Diagnosing Failures”. This technique of using the Webhook Tester site for debugging run time integrations is very useful. An added benefit is that the Webhook Tester site allows for both cloud and local based (e.g. Docker containers, Virtual Machines, etc).

To help with debugging, you can add diagnostic steps to a logic app workflow, along with reviewing the trigger and runs history. For example, you can add steps that use the Webhook Tester service so that you can inspect HTTP requests and determine their exact size, shape, and format.

Go to the Webhook Tester site and copy the generated unique URL.
In your logic app, add an HTTP POST action plus the body content that you want to test, for example, an expression or another step output.
Paste your URL from Webhook Tester into the HTTP POST action.
To review how a request is formed when generated from the Logic Apps engine, run the logic app, and revisit the Webhook Tester site for more details.

For more information, review the documentation here.

NOTE: This tool is useful for testing outside of Power Automate including any resource that has HTTP Post capabilities, examples including Azure Functions and GitHub Web hooks!

Scopes and the Try, Catch, Finally Pattern

Using scopes, actions can be linked together in a logical group allowing for evaluation of multiple actions as a whole. This comes into play when working with exception and error handling. Scopes provide statuses similar to Power Automate flows or Logic Apps themselves such as “Succeeded“, “Failed“, “Cancelled“, etc. Pieter Veenstra has a really nice approach, “Get the result of your failed actions in Power Automate” for using scopes to implement a Try, Catch, Finally pattern which i’ll discuss below.

In the image below are three scope objects titled “Try“, “Catch” and “Finally“.

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

From a recent flow run, expanding the Try block, we can see two successful actions followed by our mocked failed response from the Common Data Service:

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

The Catch scope underneath the Try scope is using the run after property of the Try scope to catch results with a status of “Failed”. If any actions inside the Try scope, at least how this example is configured, fails, the Catch scope will begin processing. The remaining actions within the Try scope are not processed.

Below is an image of the Catch scope with Tracked Properties:

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

To work with the Try scope within the Catch scope, we will use the results function which provides context to what happened within the Try scope.

Result Function

The results() function, as shown in the reference link, returns an array object. At first glance this seems fairly straight forward until we dig deeper into the context of the results output. The actions returned with the results function include the standard properties listed in Part 1 such as start and end time and tracking identifiers. You’ll also see that they include properties indicating if they were successful or not.

The image below shows a successful action named “successful_try_action” and a failed action named “Condition”. Each action includes two properties, code and message that can be used to filter the array. The successful action is in green while the failed action is in red.

Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

Finally, the below gif shows working with the Try, Catch, Finally pattern and scope and results objects to capture and report. This technique can be continued to then send data to Azure Application Insights or Azure Log Analytics as briefly shown below. I’ll cover this in an upcoming article!

7737.pastedimage1591890792104v19 Monitoring the Power Platform: Power Automate Run Time Part 2: Tracked Properties and Error Handling

Next Steps

In this article we have discussed tracking properties across actions to help supplement reporting. When examining error handling and preparing for designing resilient Microsoft Power Automate flows we examined various patterns. Utilizing retry policies, configuring the run after conditions and implementing scope can all help build an enterprise ready flow.

Index

Monitoring the Power Platform: Introduction and Index

Let’s block ads! (Why?)

Dynamics 365 Customer Engagement in the Field

Snack time

June 8, 2020 Humor

Posted by Krisgo

via fb

About Krisgo

I’m a mom, that has worn many different hats in this life; from scout leader, camp craft teacher, parents group president, colorguard coach, member of the community band, stay-at-home-mom to full time worker, I’ve done it all– almost! I still love learning new things, especially creating and cooking. Most of all I love to laugh! Thanks for visiting – come back soon

Let’s block ads! (Why?)

Deep Fried Bits

‘One Day At A Time’ Animated Adds Lin-Manuel Miranda; Sets Premiere Date

May 15, 2020 Humor

Pop TV today announced the ONE DAY AT A TIME animated special will premiere on June 16^th and include special guest stars Gloria Estefan, Melissa Fumero and Lin-Manuel Miranda. The critically acclaimed Sony Pictures Television series had its mid-season finale on April 14^th due to production stoppages as a result of COVID-19. The animated special, titled, ‘The Politics Episode,’ will be fully executed remotely and premiere on Pop TV Tuesday, June 16^th at 9:30PM ET/PT following a marathon of the current season.

Gloria Estefan and Melissa Fumero, both return to ONE DAY AT A TIME, reprising their roles, but this time, they’ll be animated. As for Lin-Manuel Miranda, he makes his debut on the series. The special will center around Penelope’s conservative cousin Estrellita (Melissa Fumero), Tia Mirtha (Gloria Estefan), and Tio Juanito (Lin-Manuel Miranda) coming to visit and with the impending election, they won’t be able to avoid fighting over politics.

Produced by Sony Pictures Television, the award-winning comedy inspired by Emmy® winner Norman Lear’s 1975 series of the same name tells the story of the Cuban American Alvarez family. The show features Penelope (Screen Actors Guild Award® winner Justina Machado), her mother Lydia (Emmy, Grammy®, Oscar® and Tony® winner Rita Moreno), Dr. Berkowitz (Stephen Tobolowsky), Schneider (Todd Grinnell)), Elena (Isabella Gomez) and Alex (Marcel Ruiz).

ONE DAY AT A TIME is produced by Act III Productions, Inc., Snowpants Productions and GloNation in association with Sony Pictures Television, with Norman Lear, Mike Royce, Gloria Calderón Kellett and Brent Miller serving as executive producers. The special is also produced by Jonas Diamond, Executive Producer and Co-Owner of Smiley Guy Studios in Toronto, who will be overseeing the animation.

Kyle Grooms Debuts New Special Titled ‘Kyle Grooms: Brain Humor’ For Amazon Prime

Let’s block ads! (Why?)

The Humor Mill

IBM claims its Neural Computer achieves record AI model training time

May 14, 2020 Big Data

In a technical paper quietly released earlier this year, IBM detailed what it calls the IBM Neural Computer, a custom-designed, reconfigurable parallel processing system designed to research and develop emerging AI algorithms and computational neuroscience. This week, the company published a preprint describing the first application demonstrated on the Neural Computer: a deep “neuroevolution” system that combines the hardware implementation of an Atari 2600, image preprocessing, and AI algorithms in an optimized pipeline. The coauthors report results competitive with state-of-the-art techniques, but perhaps more significantly, they claim that the system achieves a record training time of 1.2 million image frames per second.

The Neural Computer represents something of a shot across the bow in the AI computational arms race. According to an analysis recently released by OpenAI, from 2012 to 2018, the amount of compute used in the largest AI training runs grew more than 300,000 times with a 3.5-month doubling time, far exceeding the pace of Moore’s law. On pace with this, supercomputers like Intel’s forthcoming Aurora at the Department of Energy’s Argonne National Laboratory and AMD’s Frontier at Oak Ridge National Laboratory promise in excess of an exaflop (a quintillion floating-point computations per second) of computing performance.

Video games are a well-established platform for AI and machine learning research. They’ve gained currency not only because of their availability and the low cost of running them at scale, but because in certain domains like reinforcement learning, where AI learns optimal behaviors by interacting with the environment in pursuit of rewards, game scores serve as direct rewards. AI algorithms developing within games have shown to be adaptable to more practical uses, like protein folding prediction. And if the results from IBM’s Neural Computer prove to be repeatable, the system could be used to accelerate those AI algorithms’ development.

The Neural Computer

IBM’s Neural Computer consists of 432 nodes (27 nodes across 16 modular cards) based on field-programmable gate arrays (FPGAs) from Xilinx, a longtime strategic collaborator of IBM’s. (FPGAs are integrated circuits designed to be configured after manufacturing.) Each node comprises a Xilinx Zynq system-on-chip — a dual-core ARM A9 processor paired with an FPGA on the same die — along with 1GB of dedicated RAM. The nodes are arranged in a 3D mesh topology, interconnected vertically with electrical connections called through-silicon vias that pass completely through silicon wafers or dies.

VB Transform 2020 Online – July 15-17: Join leading AI executives at the AI event of the year. Register today and save 30% off digital access passes.

IBM claims its Neural Computer achieves record AI model training time

Above: A single card from IBM’s Neural Computer.

Image Credit: IBM

On the networking side, the FPGAs provide access to the physical communication links among cards in order to establish multiple distinct channels of communication. A single card can theoretically support transfer speeds up to 432GB per second, but the Neural Computer’s network interfaces can be adjusted and progressively optimized to best suit a given application.

“The availability of FPGA resources on every node allows application-specific processor offload, a feature that is not available on any parallel machine of this scale that we are aware of,” wrote the coauthors of a paper detailing the Neural Computer’s architecture. “[M]ost of the performance-critical steps [are] offloaded and optimized on the FPGA, with the ARM [processor] … providing auxiliary support.”

Playing Atari games with AI

The researchers used 26 out of 27 nodes per card within the Neural Computer, carrying out experiments on a total of 416 nodes. Two instances of their Atari game-playing application — which extracted frames from a given Atari 2600 game, performed image preprocessing, ran the images through machine learning models, and performed an action within the game — ran on each of the 416 FPGAs, scaling up to 832 instances running in parallel.

To obtain the highest performance, the team shied away from emulating the Atari 2600, instead opting to use the FPGAs to implement the console’s functionality at higher frequencies. They tapped a framework from the open source MiSTer project, which aims to recreate consoles and arcade machines using modern hardware, and bumped the Atari 2600’s processor clock to 150 MHz up from 3.58 MHz. This produced roughly 2,514 frames per second compared with the original 60 frames per second.

In the image preprocessing step, IBM’s application converted the frames from color to grayscale, eliminated flickering, rescaled images to a smaller resolution, and stacked the frames into groups of four. It then passed these onto an AI model that reasoned about the game environment and a submodule that selected the action for the next frames by identifying the maximum reward as predicted by the AI model.

Above: Results from the experiments.

Image Credit: IBM

Yet another algorithm — a genetic algorithm — ran on an external computer connected to the Neural Computer via a PCIe connection. It evaluated the performance of each instance and identified the top-performing of the bunch, which it selected as “parents” of the next generation of instances.

Over the course of 5 experiments, IBM researchers ran 59 Atari 2600 games on the Neural Computer. The results imply that the approach wasn’t data-efficient compared with other reinforcement learning techniques — it required 6 billion game frames in total and failed at challenging exploration games like Montezuma’s Revenge and Pitfall. But it managed to outperform a popular baseline — a Deep Q-network, an architecture pioneered by DeepMind — in 30 out of 59 games after 6 minutes of training (200 million training frames) versus the Deep-Q network’s 10 days of training. With 6 billion training frames, it surpassed the Deep Q-network in 36 games while taking 2 orders of magnitude less training time (2 hours and 30 minutes).

Let’s block ads! (Why?)

Big Data – VentureBeat

WHEN WAS THE LAST TIME YOU HEARD A WEATHER REPORT LIKE THIS?

May 5, 2020 Humor

Let’s block ads! (Why?)

ANTZ-IN-PANTZ ……

Thinking Differently: Redefining The Automotive Dealership Experience In A Time Of Crisis

May 1, 2020 BI News and Info

Nearly every driver can tell you about the time they went to a car dealership and picked out their first vehicle. It is an extremely personal experience, and dealerships have a special, customer-facing role to play in the automotive value chain.

Dealerships have also been some of the most hard-hit automotive businesses due to the current crisis. With lockdowns in effect across much of the world, consumers are not flocking into show floors. Likewise, an uncertain economic picture is leading to drivers putting their car purchases on hold.

What steps can automotive dealerships take to successfully navigate this crisis? How can they embrace technology to become more resilient in the future? In this blog, we look at some strategies auto dealerships around the world have adopted to survive and prepare for recovery.

Dealerships are adapting

Since social distancing rules and lockdowns have gone into effect, many dealerships have had to rethink their businesses and customer delivery models.

Dealerships around the world are adapting to new guidelines. In the United States, some have closed general-public sales and are selling vehicles by appointments made over the phone or online. Dealers urge sales personnel and customers to appropriately social distance while transactions are completed. In China, staff are checking employees’ and customers’ temperatures before they are allowed onsite.

Others have adopted online marketplaces where customers can purchase vehicles. In Brazil, Renault, which had invested in the industry-leading K-commerce portal, allows customers to have a truly online buying experience. Not only can buyers select and customize a vehicle, they can apply for financing and set up transactions completely online. Such end-to-end dealership experiences neatly comply with some of the most stringent social distancing guidelines.

While much of their sales staff is unable to sell in-person, dealerships in Asia-Pacific are training workers to do so online. Livestreaming car sales presentations – a sales practice commonly associated with online fashion retail – has become very popular in China. These sessions have increased 15X since the start of the crisis.

While ambiguity over the sale of vehicles remains, governments have allowed dealerships to service customers and repair vehicles. To ensure that automotive workers are protected, one dealership in the United States is limiting the number of people that can work on the shop floor at one time to observe CDC guidelines. As testing becomes more widespread, such practices will continue to be adopted around the world.

The future of dealer servicing

The current crisis has accelerated several developments that will fundamentally transform the auto dealership experience. The rise of predictive maintenance and on-demand servicing are just two trends that can harden a dealership to survive future lockdowns.

Predictive maintenance is a discipline that seeks to accurately discern when a part will fail and act before it does. In this framework, sensor-derived data is aggregated and analyzed to find subtle correlations. These hints are rigorously examined to find signs of imminent part failure. Replacing parts before a failure saves customers costs over standard preventative-maintenance procedures.

When married with on-demand servicing, this could lead to a fundamental transformation in how vehicles are serviced. For example, a dealer and car owner could be alerted of an imminent failure from the predictive analytics suite. The owner could then schedule a representative from the dealership to pick up the vehicle. Thereafter, the dealership could replace the failing part, disinfect surfaces, and deliver the vehicle back to the owner. If the repair can be done outside of the shop, the dealer’s representative could simply do it at the owner’s residence. In this way, the vehicle never suffers a catastrophic failure and social distancing is maintained.

Do you have other ideas on how dealerships can prepare for the future? Let me know on Twitter at @mannepalliAswin.

Get to know SAP Transformation Navigator, a self-service tool that helps you chart your digital transformation with SAP S/4HANA. Join our Webinar session on May 4, 2020.

Let’s block ads! (Why?)

Digitalist Magazine

DJI’s Mavic Air 2 has a flight time of 34 minutes

April 28, 2020 Big Data

DJI today unveiled the Mavic Air 2, the successor to the Mavic Air, which was released in early 2018. There isn’t much in the way of surprises — the manual leaked in full last week — but the company detailed a few of the photography features debuting on its latest mid-range, travel-friendly foldable drone.

DJI asserts that the Mavic Air 2 isn’t just a refinement of the Mavic Air, but a built-from-the-ground-up product developed with a new manufacturing process. This is reflected in the Mavic Air 2’s faster flight speed and longer flight time, the company says, as well as the drone’s dimensions and weight. It’s 570 grams — just over 100 grams heavier than the original Mavic Air (430 grams) — and only a smidge larger, at 180 x 97 x 84 millimeters compared to 168 x 83 x 49 millimeters.

The Mavic Air 2 features a 1/2-inch 48-megapixel Quad Bayer sensor, which has four photosites — one for each color pixel. This enables it to capture different exposures simultaneously and smooth out color and tone while reducing image noise as it does so. The Mavic Air 2 also has the distinction of being the first drone in the Mavic lineup that can record 4K video at 60 frames per second and 120Mbps, optionally in high dynamic range (HDR) or panoramic high dynamic range.

On the software side, the Mavic Air 2 can capture either 12-megapixel or 48-megapixel photos and slow-motion videos at 4 to 8 times speed (240 frames per second) in 1080p. Its SmartPhoto photography suite includes Scene Recognition, which taps AI to detect sunsets, blue skies, grass, snow, and trees and optimize the color, detail, and tones accordingly; Hyperlight, which takes multiple snapshots and merges them to cut down on noise and boost brightness; and HDR Photo, which automatically captures seven photos at various exposures and merges them together to improve contrast.

In addition, the Mavic Air 2 ships with a family of videography features dubbed FocusTrack. Spotlight 2.0 — which was previously reserved for higher-end DJI drones like the Inspire 2 — locks a subject in the frame while letting the pilot move the drone. ActiveTrack 3.0 selects a subject to follow automatically, employing 3D mapping tech and revamped path-finding algorithms to better recognize subjects, avoid obstacles, and re-engage when subjects occlude. Lastly, Point of Interest 3.0 — which benefits from improved surface recognition — sets an automated flight path around a target person, animal, or thing.

There’s also QuickShots, a set of pre-programmed flight maneuvers (Rocket, Circle, Dronie, Helix, Boomerang, and Asteroid) that use the Mavic Air 2’s 3-axis gimbal and electronic image stabilization for ultra-steady footage. And mid-May will see the release of an 8K “hyperlapse” feature that mimics the effect of a timelapse but with the added element of physical movement.

Beyond the Mavic Air 2’s camera chops, DJI is spotlighting the flight performance, which the company characterizes as “unparalleled” in the drone’s price range. That remains to be seen, but it’s true that the Mavic Air 2’s quoted flight time — 34 minutes — exceeds that of the Mavic Air (21 minutes), while the maximum transmission distance is substantially improved, at 10 kilometers (6.2 miles) over both 2.4GHz and 5.8GHz frequency bands versus the Mavic Air’s 4-kilometer (2.4 miles) range. (DJI’s OcuSync 2.0 tech automatically switches between the two bands based on signal strength.) As for the top speed, it’s the same as the Mavic Air: 68.4 kilometers per hour (42.5 miles per hour).

Those aren’t the only hardware upgrades of note. The Mavic Air 2 has obstacle sensors on the front and rear that warn pilots when they’re too close to an object and which can stop the drone from moving any closer to avoid collisions. Additional sensors and auxiliary lights assist with other functions, like automatic landing in difficult lighting conditions. DJI’s AirSense technology warns drone pilots of other aircraft (like airplanes and helicopters) nearby and displays their location on the controller’s screen, and the updated Advanced Pilot Assistance System (APAS 3.0) helps the Mavic Air 2 create a new path around, under, or over objects with smooth transitions and fluid movements. (DJI says that AirSense will initially only be available in North America, but that it’ll come to other regions in “summer 2020.”)

The Mavic Air 2 is available for preorder starting today at $ 799 — the same MSRP as the Mavic Air — which puts it between the smaller DJI Mavic Mini and pricier Mavic 2 Pro. It ships with a redesigned remote controller with a speaker and spring-loaded phone mount, all necessary wires and cables, and a single battery. The $ 988 Fly More package throws in two extra batteries, a case, a charging hub, and neutral-density filters.

Firm ship global dates haven’t been announced yet, but DJI says it expects the Mavic Air 2 to hit U.S. stores sometime in May. It’s available in China starting this week, and pre-orders for the rest of the world begin today.

Let’s block ads! (Why?)

Big Data – VentureBeat

Tag Archives: Time

Summary

Adding Custom Identifiers

Tracked Properties

Utilizing a system provided Correlation Id

Adding a custom Tracking Id

The Log Analytics Connector

Creating Custom Tables

Thoughts on Controlling the Collector

The Case for Application Insights

Utilizing the Application Insights REST API directly

Building the Message Body

Utilizing Azure Functions and Custom Connectors

Choosing between Log Analytics and Application Insights

Next Steps

Index

The Role of CRM

Better Algorithms for Fewer Returns

Summary

Triggers

Secure Inputs and Outputs

Concurrency and Parallelism

Schema Validation

Trigger Conditions

Trigger Object

Workflow

The Workflow Time Stamps and Tracking Identifiers

The Workflow Run Object

The Workflow Tags Object

Capturing Connection and Action Responses

The Action and Actions Functions

Action Outputs

Output Header

Output Body

Next Steps

Index

Summary

Action Tracked Properties

Action Headers Example

Timestamp Example

Handling and Capturing Errors in Actions

Retry Policies

Mock Responses

Throttling with Azure Logic Apps

Webhook Tester Site and runtime debugging

Scopes and the Try, Catch, Finally Pattern

Result Function

Next Steps

Index

Like this:

About Krisgo

Share this:

Like this:

The Neural Computer

Playing Atari games with AI

Dealerships are adapting

The future of dealer servicing

Recent Posts

Categories

Archives