How Subscription works in case of multiple calls to a service having RequestResponse Port as Direct Bound

huangapple go评论49阅读模式
英文:

How Subscription works in case of multiple calls to a service having RequestResponse Port as Direct Bound

问题

我有一个名为“MainService”的BizTalk Orchestration托管模式,它作为服务存在。

它有一个RequestResponcePort,该端口与多个不同过滤器的Receive Shapes直接绑定,例如一个Receive Shape的过滤器为Bts.Operation='ABC'。它的工作流程包括以下步骤:

  1. 接收请求模式 - Schema1
  2. 运行一些业务逻辑
  3. 用模式响应 - schema2

现在我有另外两个调用上述服务的服务,

Service1 -

  1. 接收类型为'X'的消息
  2. 将'X'转换为Schema1
  3. 调用“MainService” -> RequestResponsePort(直接绑定和Operation='ABC')
    请求模式 - Schema1
    响应模式 - schema2
  4. 将Schema2转换为'Y'并发送作为响应

Service2 -

  1. 接收类型为'C'的消息
  2. 将'C'转换为Schema1
  3. 调用“MainService” -> RequestResponsePort(直接绑定和Operation='ABC')
    请求模式 - Schema1
    响应模式 - schema2
  4. 将Schema2转换为消息类型'D'并发送作为响应

我知道在这种情况下,Service1和Service2都将正确收到它们的响应,但我想了解订阅将如何在这里工作,订阅将根据什么决定,因为Service1和Service2都期望从“MainService”获得相同的响应消息类型。
例如,基于interchangeId或correlationToken等的订阅,如果您能指导我在哪里可以找到它们的确切订阅标准,无论是在数据库中还是在AdminConsole中(我尝试查看但无法理解)。

我创建了相同的情景以进行理解,它确实有效,但我无法理解基于什么订阅标准它正确地返回响应给相应的服务。

英文:

I have BizTalk Orchestration hosted Schema as a Service named as "MainService"

It has RequestResponcePort which is Direct bound with Multiple Receive Shapes with Different Filter like one Receive Shape has filter as Bts.Operation='ABC'. Its workflow has below steps

  1. Receive Request schema - Schema1
  2. Run some business logic
  3. Respond with schema - schema2

Now I have two other services which calls above service,

Service1-

  1. Receive message of type 'X'
  2. Transforms 'X' to Schema1
  3. Call "MainService" -> RequestResponsePort (Direct bound and Operation='ABC')<br>
    Request Schema - Schema1<br>
    Response schema - schema2
  4. Transform Schema2 to 'Y' and send out as a response

Service2-

  1. Receive message of type 'C'
  2. Transforms 'C' to Schema1
  3. Call "MainService" -> RequestResponsePort (Direct bound and Operation='ABC')
    Request Schema - Schema1<br>
    Response schema - schema2<br>
  4. Transform Schema2 to the message type of 'D' and send out as a response

I know in this scenario Service1 & Service2 will get their responses correctly but I want to understand how the subscription will work here
based on what the subscription will be decided as both the services Service1 and Service2 are expecting same messageType as response from "MainService".
e.g. subscription based on interchangeId or correlationToken etc

If you could advise me where can I find the exact subscriptions criteria for them in DB or in AdminConsole (I try to check but I could not understand)

I have created same scenario to understand, it worked however I could not understand based on what subscription criteria it correctly returns responses to corresponding services

答案1

得分: 0

你可以从BizTalk管理控制台查询订阅。在新查询中,选择订阅,在第二行选择服务名称,然后在右侧的下拉菜单中选择您想要的服务名称,然后单击运行。

然后,您将看到如下结果,并可以展开它以查看精确的订阅详细信息。

它们将是激活订阅,即将触发编排的订阅,或者是实例订阅,其中编排正在等待(自动)相关的响应。很多时候,它们看起来会像这样:

http://schemas.microsoft.com/BizTalk/2003/system-properties.CorrelationToken == {GUID}
英文:

You can query the subscriptions from the BizTalk Admin console. From New Query, select Subscriptions, on the second line select Service Name, and in the drop down to the right select the service name you want and click Run.

How Subscription works in case of multiple calls to a service having RequestResponse Port as Direct Bound

Then you will see results like below, and you can expand it to see the exact subscription details.

How Subscription works in case of multiple calls to a service having RequestResponse Port as Direct Bound

They will either be an Activation Subscription i.e. those that will trigger of the Orchestration, or Instance Subscription, on where an Orchestration is waiting for a (auto)correlated response. Quite often these will look like

   http://schemas.microsoft.com/BizTalk/2003/system-properties.CorrelationToken == {GUID}

huangapple
  • 本文由 发表于 2023年6月1日 16:13:04
  • 转载请务必保留本文链接:https://go.coder-hub.com/76379902.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定