none
BizTalk and Async REST services RRS feed

  • Question

  • Hello everyone,

    I'm wondering if the BizTalk web-http adapter supports async REST services and how BizTalk deals with them. I have an integration that I'll have to do with an async REST service, but I'm struggling to understand how can BizTalk integrate with it, I don't find information on this topic.

    Does anyone has experience with such services? Or can point me into the right direction?

    Thank you

    Monday, May 2, 2016 10:36 AM

Answers

  • Okay so this specific case is to have BizTalk consuming Sales Force Bulk API.

    The service can take some time and for that reason is asynchronous. So I was trying to understand if the send port would say waiting for some time for the response (I don't find very probable) or we get a synchronous response with a token that we can use to pool the service and continue the flow.

    But like you said, I'm probably over thinking this.

    Yes, you are correct - the SendPort will not 'wait'. In fact in our implementation, we use a orchestration loop to call SalesForce, as there is a limitation on the number of records SalesForce can return on a call.

    It returns a QueryMore Id(like a Token), that you can use on the next call and keep querying until SalesForce returns a empty QueryMore Id. Then you know that you are done with the entire operation. Fairly straightforward.

    Once you start implementing, you will find the pieces falling in place.


    Thanks Arindam




    Monday, May 2, 2016 1:46 PM
    Moderator
  • Okay so this specific case is to have BizTalk consuming Sales Force Bulk API.

    That depends entirely on the SF Operation.  So, you'll either have to ask them (good luck with that) or just try it and see what happens.

    Basically, if you post the data and they don't return anything more than an OK immediately, then it's Async data operation.  Then I imagine you have to poll them for a result.

    If they actually process all the data and return a response based on that data on the same http request, then it's a Synchronous data operation.

    Note, the http call is always sync.  The data operation can go either way.


    Monday, May 2, 2016 1:54 PM
    Moderator

All replies

  • Hi Ricardo

    It depends on your exact requirements - BizTalk can handle async WCF services - async REST is just another similar pattern. What are the exact requirements of the service? Async REST could mean, but not limited to-

    1) You make a call to your REST service operation, and get back a token. You later call the service with the token to get the actual results - PULL model.

    2) You make a REST call to service operation(optionally passing your callback URL). After a duration, the service calls a URL exposed by you to return the results - PUSH model.

    Both models can be implemented within BizTalk. There is nothing special to them - you just have to know how to call REST endpoints from BizTalk, and how to expose REST endpoints from BizTalk(if option2. is needed).

    Ref-

    http://soa-thoughts.blogspot.in/2015/01/biztalk-server-2013-r2-consuming-json.html

    http://www.quicklearn.com/blog/2013/08/16/biztalk-server-2013-support-for-restful-services-part-15/

    https://seroter.wordpress.com/2012/11/12/exploring-rest-capabilities-of-biztalk-server-2013-part-1-exposing-rest-endpoints/



    Thanks Arindam


    Monday, May 2, 2016 10:48 AM
    Moderator
  • What exactly do you mean Async REST Service?

    I ask because, well, there's really no such thing as an asynchronous http service.  You can handle REST operations asynchronously, which BizTalk does already.

    Now, if you mean async as in the more common Callback pattern, then all you really have is two REST operations.  One where you call them, then whenever they're ready, they call you back.

    Don't over think it.  There's likely nothing special about what you need to do.

    Monday, May 2, 2016 11:50 AM
    Moderator
  • Okay so this specific case is to have BizTalk consuming Sales Force Bulk API.

    The service can take some time and for that reason is asynchronous. So I was trying to understand if the send port would say waiting for some time for the response (I don't find very probable) or we get a synchronous response with a token that we can use to pool the service and continue the flow.

    But like you said, I'm probably over thinking this.

    Monday, May 2, 2016 1:43 PM
  • Okay so this specific case is to have BizTalk consuming Sales Force Bulk API.

    The service can take some time and for that reason is asynchronous. So I was trying to understand if the send port would say waiting for some time for the response (I don't find very probable) or we get a synchronous response with a token that we can use to pool the service and continue the flow.

    But like you said, I'm probably over thinking this.

    Yes, you are correct - the SendPort will not 'wait'. In fact in our implementation, we use a orchestration loop to call SalesForce, as there is a limitation on the number of records SalesForce can return on a call.

    It returns a QueryMore Id(like a Token), that you can use on the next call and keep querying until SalesForce returns a empty QueryMore Id. Then you know that you are done with the entire operation. Fairly straightforward.

    Once you start implementing, you will find the pieces falling in place.


    Thanks Arindam




    Monday, May 2, 2016 1:46 PM
    Moderator
  • Okay so this specific case is to have BizTalk consuming Sales Force Bulk API.

    That depends entirely on the SF Operation.  So, you'll either have to ask them (good luck with that) or just try it and see what happens.

    Basically, if you post the data and they don't return anything more than an OK immediately, then it's Async data operation.  Then I imagine you have to poll them for a result.

    If they actually process all the data and return a response based on that data on the same http request, then it's a Synchronous data operation.

    Note, the http call is always sync.  The data operation can go either way.


    Monday, May 2, 2016 1:54 PM
    Moderator