Authenticating Salesforce REST API calls to custom Apex endpoints

Authenticating Salesforce REST API calls to custom Apex endpoints

Seroter has shown us how to call the Force.com REST API from BizTalk Server and we used this to successfully call standard Force.com objects like .salesforce.com/services/data/v34.0/sobjects/contacts”>https://<blah>.salesforce.com/services/data/v34.0/sobjects/contacts. We could not use this to call custom force.com objects like .salesforce.com/services/apex/ContactMapping”>https://<blah>.salesforce.com/services/apex/ContactMapping unless we modified the published WCF Behaviour for authentication. Thanks to Aravindh Kathiresan for working all this […]
Blog Post by: mbrimble

Azure Logic Apps Monthly Update – November 2015

In a community driven approach from Microsoft, the monthly Google Hangout session from the Azure Logic Apps team – sixth in the series – happened on December 3, 2015. We recommend you to read our earlier blog posts to understand the progress made by the Logic Apps team over the last few months. (July, September, […]

The post Azure Logic Apps Monthly Update – November 2015 appeared first on BizTalk360 Blog.

Blog Post by: Sriram Hariharan

Find BizTalk map by source and destination MessageType

Find BizTalk map by source and destination MessageType

In a current integration scenario we are heavily using dynamic transforms in our solution. The combination with the Business Rules Engine (that holds the logic to determine the required output message version) makes it possible to map to the desired message format and version for a given partner.

The problem in our case was that we don’t now the version of the assembly that holds the BizTalk maps (caused by our build server setup). Otherwise we would have been able to store the MapName and AssemblyName in the BRE like showcased in this MSDN sample. Thanks to this query against the BizTalkMgmtDb we are able to find the correct map currently deployed on BizTalk Server. The query needs the incoming message type and the destination message type. (in our solution the destination message type is dynamically returned by the BRE)

Sample output of the query:

2015-12-05 12_06_20-SQLQuery1.sql - wp0905.BizTalkMgmtDb (ATOMIUM_JMSAI83 (51))_ - Microsoft SQL Ser

Find BizTalk map by source and destination MessageType

Find BizTalk map by source and destination MessageType

In a current integration scenario we are heavily using dynamic transforms in our solution. The combination with the Business Rules Engine (that holds the logic to determine the required output message version) makes it possible to map to the desired message format and version for a given partner.

The problem in our case was that we don’t now the version of the assembly that holds the BizTalk maps (caused by our build server setup). Otherwise we would have been able to store the MapName and AssemblyName in the BRE like showcased in this MSDN sample. Thanks to this query against the BizTalkMgmtDb we are able to find the correct map currently deployed on BizTalk Server. The query needs the incoming message type and the destination message type. (in our solution the destination message type is dynamically returned by the BRE)

Sample output of the query:

2015-12-05 12_06_20-SQLQuery1.sql - wp0905.BizTalkMgmtDb (ATOMIUM_JMSAI83 (51))_ - Microsoft SQL Ser

Find BizTalk map by source and destination MessageType

Find BizTalk map by source and destination MessageType

In a current integration scenario we are heavily using dynamic transforms in our solution. The combination with the Business Rules Engine (that holds the logic to determine the required output message version) makes it possible to map to the desired message format and version for a given partner.

The problem in our case was that we don’t now the version of the assembly that holds the BizTalk maps (caused by our build server setup). Otherwise we would have been able to store the MapName and AssemblyName in the BRE like showcased in this MSDN sample. Thanks to this query against the BizTalkMgmtDb we are able to find the correct map currently deployed on BizTalk Server. The query needs the incoming message type and the destination message type. (in our solution the destination message type is dynamically returned by the BRE)

Sample output of the query:

2015-12-05 12_06_20-SQLQuery1.sql - wp0905.BizTalkMgmtDb (ATOMIUM_JMSAI83 (51))_ - Microsoft SQL Ser

Logic Apps Roadmap for 2015-2016

Logic Apps Roadmap for 2015-2016

If you missed the @logicappsio LogicAppsLive community webcast (with Kevin Lam and Jon Fancey) last night, go watch it here: https://www.youtube.com/watch?v=x4JdsPIHomM.

During this webcast, they gave us the current road map for Logic Apps for the next 9 months.

Here’s the slide:

There’s quite a bit of content here, but here’s what we found out from the web cast:

1.PowerApps

Besides the new metrics and monitoring improvements, there is now Logic Apps support inside of PowerApps called PowerApps LogicFlows – and this uses the new designer. Some I’m guessing if you sign up for the PowerApps preview today, you’ll probably get to see the new designer. There’s even help on doing this here: https://powerapps.microsoft.com/en-us/tutorials/multi-step-logic-flow/.

2.Designer Improvements

The new designer will be available in preview from early spring 2016:

  • The new designer will be available in preview early next year, during a logic apps refresh and will let you see the implicit control flow in a logic app.
  • There are some architectural alignments related to the PowerApps release this week e.g. API Management capabilities, API Apps and Connectors now all use exactly the same backend infrastructure for PowerApps and Logic Apps.
  • You’ll be able to use any app that has a Swagger endpoint in the new designer, and it will appear with its own card etc. So any app: API Apps that come with Logic Apps, your own API apps, or 3rd party apps, as long as they have a Swagger endpoint.

3.Enterprise Integration Pack Preview

Coming in late spring 2016 is the preview of a new Enterprise Integration Pack (EIP):

  • A set of capabilities targeted at Enterprise integrators, the sort of things that BizTalk services provides today e.g. validate, extract, transform and route VETR); pipeline capabilities (validate messages, pull properties out of messages); B2B capability (X12 and AS2 support); and lastly Hybrid APIs.

4.Logic Apps GA

Early summer will bring Logic Apps GA!

  • Remainder of connectors you see in Logic Apps today will be available.
  • Plus a whole bunch of connectors that won’t be available in preview but will be new with GA.

5.Enterprise Integration Pack GA

In late summer the EIP will GA, bringing with it more enterprise capabilities such as:

  • Disaster Recovery.
  • Tracking improvements.

All in all, this looks very exciting – it’s really good to see some enterprise capability coming to Logic Apps!