Close

Logic App

To design a Logic App, click the link Triggers and Actions.

Goto LogicApp Designer

Below is an example of a Logic App. The Logic App receives a Http Request via a Http Listener. The Http Listener acts as a trigger. The other API Apps in the Logic App are what we call actions. Note that the API Apps like the Http Listener and the BizTalk XML validator are created before creating the Logic App. You can use multiple instances of an API App in one Logic App. In this example you can see that multiple instances of the same Http Listener are used.

LogicApp Designer

Before we go on, I’d like to add a little note. When you create a Logic App a list of available triggers, actions and connectors will be added to a toolbox which is available on the right hand side of the Logic App designer. The list of API Apps is limited to those already provisioned in your App Service Plan. I once noticed this toolbox was minimalized. Only after looking very close I noticed there is a maximize icon in the right hand corner of the toolbox. Take a close look at the screenprint below to show it again in full size. By the way, when you use an API App in a Logic App and you change it’s design afterwards, you don’t have to remove the API App and add it again to the Logic App. It simply gets updated without being added again.

ApiAppToolBox

Now let’s zoom in to the different triggers and actions. The Http Listener gives subsequent actions access to the body of the message. As a little side note. You can see the name you specified for the Http Listener (or any other API App) only after you click the information (i) button after the text Receive Http Request. It would have been more intuitive if you had seen the name in the red banner.

Http Listener

After receiving the request, the request is first validated. Note that the input xml is retrieved from the trigger: @{triggers().outputs.body.content}. The @ simply means you are referring to a function. The function is expressed in the Workflow Definition Language. For a helpful link, see: WDL. The validation result is not returned to the caller immediately. The flow is further executed and only later an http response is returned to the caller based on the validation result. You can specify different schemas in one validation step. That means you can receive different kinds of xml documents via the http listener.

XML Validator

The next step is the BizTalk Transform Service. The BizTalk Transform Service maps the incoming xml document to the schema required by the SQL Connector. After insert in BizTalk the different xml messages are assembled into one big xml file. That means that the different xml messages are not assembled via a map in the BizTalk Transform Service. The BizTalk Transform makes use of a so-called .trfm file, not from a BizTalk .btm file or an xslt file. The trfm file can be assembled via a visual mapper similar to the BizTalk mapper. The Mapper can be accessed in Visual Studio after you have installed the BizTalk Services (or MABS) SDK. Note that you can add different maps to a BizTalk Transform shape. The correct map is selected based on the input xml document. Add a condition like: @equals(body(‘xmlvalidatorperson’).Result,bool(‘True’))

TransformLogic

The next step is the SQL Connector. The SQL Connector takes the input from the transform step. If you want to insert into two different tables, than you need two SQL Connectors. To select the correct SQL Connector you need to specify a condition. The condition refers to the schema name property of the validate step. Finally be aware that the action Insert Into Person (XML) is selected when you add the SQL Connector to the Logic App Designer.

SQLConnector Logic SQLConnector 2Logic

The last action you need is a Http Listener to return the result of the REST call. Notice that an Http 500 is returned when the result of the validation is false: @equals(body(‘xmlvalidatorsampleschemas’).Result,bool(‘False’)). The RequestId is taken from the Http Listener that acts as a trigger. The content is set to the error description that is the result of the validation: @{body(‘xmlvalidatorsampleschemas’).ErrorDescription}. The configuration of the Http 200 Listener is similar. Only note that you have to add the Http Listener twice, that is, once after each successful insert. Also the content can’t be set to the error description, but in this case to the output : @{body(‘sqlconempgateway’).OutputXml}

HttpListener500Logic HttpListener200Logic

Logic Apps with an Http trigger can be tested via Postman:

Postman

1 thought on “Logic App

Leave a Reply

Your email address will not be published. Required fields are marked *