Azure Logic App FTP Connector and Properties

Posted: January 27, 2019  |  Categories: Azure BizTalk

This blog makes some comments about the Logic App FTP Connector and Properties.  In particular it records my experiences migrating a BizTalk interchange to Azure components. Furthermore I hope to illustrate some points that other logic app newbies might at first find hard to work out.

BizTalk Solution

In the first place let’s consider a AS2/EDIFACT BizTalk solution described in my previous post. To summarize this interface receives an XML order by FTP and sends a AS2/EDIFACT order.

Notably, the key components are;

  • Trading partner agreements
  • EDIFACT encoding
  • XML schemas
  • XSLT transformations
  • FTP protocol
  • HTTP over AS2 protocol
  • MDN acknowledgements.
Azure solution

In general, the future state replaces the BizTalk components with this list.

  • Firstly, a pre-processing logic app to route the orders.
  • Secondly, Service bus topics for publishing and subscribing.
  • Thirdly, post-processing logic apps that subscribe to a supplier’s orders, transform them to AS2/EDIFACT orders and then send them to the customer.
  • Fourthly an integration account for certificates, agreements, maps and schemas.

Comments about the FTP connector and Properties

Sometimes an expert example fails to show some little points.  I  highlight three of these points here. As an illustration let’s walkthrough the order pre-processing logic app shown above. Wiring it together was easy but testing it successfully was much more difficult.

The pre-processing starts with a FTP  pickup from the ERP FTP folder. The current implementation currently uses the same FTP folder for all supplier purchase orders.

Secondly, the second action converts the flat file to XML. This canonical XML contains all the properties required to route the order to the correct supplier and find the correct EDIFACT and AS2 agreements. This reuses the existing BizTalk schema.

Thirdly, the third action transforms the XML to canonical XML.

Finally , a final action puts the canonical XML on a service bus topic. All canonical XML PO messages are less then 7Kb.

Unit testing  using WINSCP to FTP order files to the FTP pick folder failed miserably on the first attempt. The FTP trigger failed to pick up the files. Finding the solution took an hour or so until I understood the meaning of this sentence in the FTP connector reference.

The triggers work by polling the FTP file system, and looking for any file which has been modified since the last poll. Certain tools allow the file modification time to be preserved. In such cases, you need to disable the feature for your trigger to work.

In other words, if you copy files but don’t change the modified date time to a value greater than that of the last poll the FTP connector will not pick your files up. Sure enough on disabling file preservation in WINSCP the unit test was successful.

I really think highlighting this tip in the logic app FTP documentation would help many newbies.

Comments about brokered message properties

Moving on now to a comment about assigning properties to messages. The order message that goes to the service bus topic needs a property called suppliercode that subscribers can filter on. Although I could see the box on the send to service bus action I could not find any examples of what to put in it. Thus I have shown an example above. You just simply add a JSON string representing the key-value pair for the property.

How do you use xpath with XML containing namespaces?

As an aside if I use xpath in the workflow definition to get the suppliercode it always fails in my hands if an XML namespace is present in the XML. The expression below contains valid xpath but requires string escaping to save in the logic app. I could not work out how to escape this string properly and still get the xpath result because of the embedded namespace.

xpath(body(‘Flat_File_Decoding_E360_Purchase_Order_FF’),’/*[local-name()=’E360SupplierOrders’ and namespace-uri()=’http://BidvestAU_E360_Schema.E360FlatFileSchema’]/*[local-name()=’E360SupplierOrder’ and namespace-uri()=”]/*[local-name()=’TradingPartnerID’ and namespace-uri()= ‘/*[local-name()=’E360SupplierOrders’ and namespace-uri()=’http://BidvestAU_E360_Schema.E360FlatFileSchema’]/*[local-name()=’E360SupplierOrder’ and namespace-uri()=”]/*[local-name()=’suppliercode’ and namespace-uri()=”]’)

 

Instead, my workflow definition first converts the XML to JSON before walking the tree to get the value.

json(body(‘Flat_File_Decoding_E360_Purchase_Order_FF’))[‘E360SupplierOrders’][‘E360SupplierOrder’][‘suppliercode’]

A workflow definition expression example showing  xpath with XML that has a namespace would be very useful to this author.

Conclusion

Walking through one of my logic apps I have recorded my experiences showing some simple problems I overcame.  I hope my comments about the xpath workflow definition expression, Logic App FTP Connector and Properties might be useful to other newbies.

BizTalk360
BizTalk Server

Over 500+ customers across
30+ countries depend on BizTalk360

Learn More
Serverless360
Azure

Manage and monitor serverless
components effortlessly

Learn More
Atomicscope
Business Users

Monitor your Business Activity in iPaaS
or Hybrid integration solutions

Learn More

Back to Top