现在的位置: 首页 > 综合 > 正文

深入biztalk中各种端口绑定方式(二)– specify later(以后指定)

2011年07月09日 ⁄ 综合 ⁄ 共 2388字 ⁄ 字号 评论关闭

一、  绑定方式 – specify later(以后指定)

这种绑定方式是在biztalk中使用最多的一种绑定方式,一般的端口绑定都是用这种方式,设计时orchestration的端口设置为“specify later”,biztalk项目部署后在biztalk控制台配置这个应用程序,新建相应的物理端口跟orchestration的端口绑定。

只是为了说明这种绑定方式,设计一个极简单的测试场景。

1、 测试场景

有一个消息,类似这样的:

<ns0:Person xmlns:ns0="http://BindingSpecifyLater.SimpleInput">

  <id>id_0</id>

  <name>name_0</name>

</ns0:Person>

把它放在一个In目录中,通过file适配器读取文件,进入到orchestration中,这个流程这样的:



Figure 3. specify later
测试流程

整个流程就就简单的传送一个消息,就是上面那个消息的架构,Port_Input_Person端口设置为:单向、接收、以后绑定。Port_Output_Person端口设置为:单向、发送、以后绑定。

项目部署好后,在biztalk控制台配置这个应用程序。

Port_Input_Person端口绑定一个接收端口,端口的接收位置配置为file adapter,指向预设的In目录,读取目录中的以xml为后缀的文件。

Port_Output_Person端口绑定一个发送端口,发送端口配置为file adapter,指向预设的Out目录,写消息为%MessageID%.xml文件。

2、 Biztalk控制台中查看订阅

Biztalk控制台提供了很方便查看已产生的订阅的方法,可以用更直观的形式反映保存在数据库中的订阅关系。


Figure 4.
查询订阅

biztalk控制台中,在左边目录树中选“Biztalk Group”,在右边的“Group Overview”面板中选择“New Query”标签,这里可以选择查询服务实例、挂起的服务实例、订阅等等。我们选择查看订阅,然后点击“Run Query”按钮,下面的窗口就会列出所有已经产生的订阅。

3、 Orchestration订阅接收端口

双击第一个订阅,这个订阅是Orchestration订阅file接收端口进来的消息:


Figure 5. Orchestration
订阅接收端口

在弹出的窗口中“General”标签的是订阅主体,反映的是Subscription消息订阅表中的内容,看一下这里的内容:

Service class是订阅消息的服务类型,这里是Orchestration类型。

Service name是订阅消息的具体服务,这里是BindingSpecifyLater.BizTalk_Orchestration1, BindingSpecifyLater, Version=1.0.0.0, Culture=neutral, PublicKeyToken=380d269ec565a18c,就是上面设计的那个流程。

再看“Express”标签:


Figure 6. Orchestration
订阅接收端口的订阅条件

这里反映的是这个订阅的订阅条件,就是这个订阅在PredicateGroup谓词组对应表,订阅谓词表中的内容。可以看到这里有两个条件:

Subscription

{

    ORGroup0

    {

        BTS.ReceivePortID == {7DA3DB40-8E1B-47DB-AF1B-078E77F19372}

        AND

        BTS.MessageType == http://BindingSpecifyLater.SimpleInput#Person

    }

}

从这里的订阅条件可以看出,Specify Later绑定,Orchestration接收端口绑定物理接收端口时,绑定动作产生的订阅条件是:消息必须来自绑定的那个端口,消息的类型必须是Orchestration中这个接收端口的指定的消息类型。只要满足这两个条件,消息就会被路由到这个Orchestration

4、  发送端口订阅Orchestration

biztalk控制台,双击第二个订阅,这个订阅是file发送端口订阅Orchestration发出的消息:


Figure 7.
发送端口订阅Orchestration

General”标签中:

Service class是订阅消息的服务类型,这里是Messaging类型,就是Messaging InProcess,表示一般的端口。

Service name是订阅消息的具体服务,这里是SendPort_binding,就是跟Orchestration绑定的发送端口。


Figure 8.
发送端口订阅Orchestration的订阅条件

Express”标签中,显示这样的订阅条件:

Subscription

{

    ORGroup0

    {

        BTS. SPTransportID == {54ECBCE9-AA7F-4DB1-B2CC-B97CF5F8D4CE}

    }

}

从这里的订阅条件可以看出,Specify Later绑定,物理发送端口跟Orchestration的发送端口绑定时,绑定动作产生的订阅条件是:消息中BTS. SPTransportID属性指向这个物理发送端口的一个通道(一般指向这个发送端口的基本通道)。这个绑定动作还对Orchestration的发送端口产生作用,绑定后,消息经过Orchestration的发送端口时,端口会在消息中增加这个BTS. SPTransportID属性,属性的值就是绑定的物理发送端口的基本通道的GUID。这样,从这个Orchestration的发送端口出来的消息就会被路由到绑定的物理发送端口。

抱歉!评论已关闭.