ORACLE企业总线OSB之MessageFlow开发参考.docx

ORACLE企业总线OSB之MessageFlow开发参考.docx

《ORACLE企业总线OSB之MessageFlow开发参考.docx》由会员分享，可在线阅读，更多相关《ORACLE企业总线OSB之MessageFlow开发参考.docx（32页珍藏版）》请在冰豆网上搜索。

ORACLE企业总线OSB之MessageFlow开发参考

OSB的MessageFlow开发参考_V0.1

MessageFlowComponents

一个messageflow由一系列的组件构成，这些组件的作用在于定义routing的逻辑以及当message在proxyservice中传递时如何控制它们。

Nodes用于配置在messageflow中如何routemessage，而stages和actions则用于处理和转换这些messages

大部分处理逻辑在pipelines中配置。

一个pipeline就是一系列stages，用于表示一个无分支的单线处理路径。

实现一个pipeline要同时配置requestpipeline和responsepipeline

两个重要的node：

Pipelinepairnode:

一个pipelinepairnode由一个requestpipeline和一个responsepipeline组成。

一个pipelinepairnode最多只能接一个后续node。

当OBS运行到pipelinepairnode时，首先运行requestpipeline，当responsemessage返回时，OSB处理responsepipeline。

request和response两个pipeline执行的路径的顺序是相反的。

Routenode:

route的作用在于使request/response与其他service进行交互。

它实际上表示了在proxyservice中request与response之间的分界（boundary）。

当一个routenode发送（dispatch）一个requestmessage后，request就已经处理完成。

当routenode接收到responsemessage时，则开始response的处理。

Routenode支持条件路由以及request和responsemessage的转换。

在routenode后面不可再接后续结点。

MessageExecution

以下是一个messageflow执行过程中的路径

首先从RequestProcessing开始

RequestProcessing：

startnode（request从这里开始）->Pipelinepairnode（只处理requestpipeline）->Branchnode（根据分支表选择要执行的分支）->Routenode（只运行requesttransformations）

当webservice服务端返回response，接下来进入ResponseProcessing

ResponseProcessing：

Routenode（只运行response相关的transformations）->Branchnode（无视branchnode直接进入其上一个node）->Pipelinepairnode（只运行responsepipeline）->startnode（将response返回调用webservice的client）

ActionDemo

PrerequisiteKnowledge

在阅读下一节之前，你需要了解一下内容：

1、对XQuery、XPath、XSLT的函数和表达式语法有一定了解。

2、对OSB的MessageContext的相关知识有一定了解。

3、对OSB的MessageFlow调试（OSBTestConsole）相关知识有一定了解。

4、输入是指在当前MessageFlow中Action的实际输入状态。

5、输出是指对proxy的MessageFlow进行调试后，查看调试输出的结果。

CommunicationActions

DynamicRouting

基于一个XQueryResource动态地设定ServiceName，从而动态地路由消息（Message）到指定的BusinessService（根据ServiceName指定）。

DynamicRouting只能在一个Route结点内添加，并且在它后面不可再添加Action

Use

Expression：

XQueryExpression，应输入内容的格式如下：

route>

serviceisProxy='false'>{$service}

service>

operation>{$operation}

operation>

route>

说明：

-isProxy表示调用的是否是ProxyService，如果是则为true；否则为false。

-$service输入SerivceName，此处应输入service在ProjectExplorer中的全限定名（thefullyqualifiedservicename）

比如SAP_PS/iS_WS_SAP_ProjectInfoService/WS_SAP_ProjectInfoService_bs

-$operation输入要执行的operation名称，可为空。

operation>结点为可选结点

RequestActions：

同RouteAction中的操作。

ResponseActions：

同RouteAction中的操作。

关于XQueryResource：

要实现DynamicRouting，首先要建立一个XQueryResource或者准备一个XML文件。

XQueryResource或XML文件的内容为一个路由表（aroutingtable），用于将一个逻辑标识符（alogicalidentifier，比如RequestMessage中表示区域编码的字段）同一个物理标识符（aphysicalidentifier，比如要调用OSB中Service的全限定名）建立关联，逻辑标识符一般是从RequestMessage中解析的输入参数，而物理标识符则表示要调用Service的全局名称。

具体实现：

在Route结点中，首先将已创建的XQueryResource由Assign操作赋给一个自定义的messagecontextvariable。

然后根据相关的逻辑标识符（alogicalindentifier）在这个variable中查找对应的物理标识符（aphysicalindentifier）（一般通过XQueryExpression实现），根据物理标识符即可执行DynamicRouting操作。

Example

输入：

首先设计一个如下的MessageFlow

因为DynamicAction只能在Route结点执行，所以Assign操作放在之前的Pipeline的Stage中，用来动态生成DynamicAction需要的Service名，如下：

$routingtable表示新创建的XQueryResource

内容如下

$logical_identifier表示从RequestMessage解析的字段值

$physical_identifier表示根据$logical_identifier从$routingtable中查到的服务名，使用XQueryExpression实现，为

Route结点的设置如下

XQueryExpression表达式为

输出：

ResponseMessage显示服务成功

查看MessageFlow

在pipeline的request阶段，Assign了三个自定义的messagecontextvariable，用来做DynamicRouting

可以看到根据$logical_identifier，Routing到名称为caotyBs1的BusinessService

RoutingTable

功能同DynamicRouting类似，根据XQueryExpression的结果进行条件判断，由判断结果Routing到不同的Service，相比DynamicRouting操作更快捷。

Use

Expression：

XQueryExpression，根据其得到的结果进行条件比较。

Operator比较条件，有=、!

=、<、<=、>、>=几个，后面的空格填入要比较的值（value）。

Service：

选择要Routing到的Service，以及这个Service要执行的Operation（如果选中Useinboundoperationforoutbound，则无需选择，表示这个Service执行与inboundvariable中同样地operation）

表示如果上一个条件不满足，则判断当前条件。

表示如果以上所有的条件都不满足，则执行此Default条件

Example

输入：

如上图所示，XQueryExpression解析requestmessage中的某一结点（ProjectCode），判断其值若为1则Routing至caotyBs1，若为2到caotyBs2，若为其他值到SapPrjNotifyWS_bs；同时这些Service都执行同inbound相同的Operation。

输出：

ResponseMessage显示成功

查看MessageFlow，显示Routing到的Service为SapPrjNotifyWS_bs。

因为根据输入的结果

判断的字段ProjectCode的值为1111，根据输入，当其不等于1或2的情况下，执行Default条件的Service

Publish

为一条message指定一个静态的targetservice，并配置如何封装（package）并发送message。

当添加了一个PublishAction后，实际上RequestMessage将要发送到的Service就变为Publish中设定的Service，原来的BusinessService无效，新设定的Service则会将返回的ResponseMessage返回给ProxyService处理，且可以在PublishAction外部执行MessageProcessingActions、ReportingActions等操作对MessageContextVariable进行处理。

需要说明的是，当在PublishAction内部添加Action对MessageContextVariable进行修改时，只是修改它们的拷贝，一旦出了PublishAction的范围，如进入下一个Action，所有的MessageContextVariable仍为PublishAction处理之前的状态。

Use

Service：

选择任一ProxyService或BusinessService，作为RequestMessage要发送的Service。

AddanAction：

对要发送到Service的Message，添加Action配置如何封装（Package）Message以及如何将Message发送至Service。

Example

输入：

如上图，在RequestActions阶段做了如下操作：

1、PublishAction设置Serivce名为caotyBs2，即把RequestMessage发送到caotyBs2服务，2、在PublishActions中对RequestMessage进行预处理。

修改caotyBs2中$outbound的request属性的headers，增加一个自定义Name和Value为Caoty-Header。

3、再添加一个DeleteAction，对ResponseMessage中body的XML格式的内容，删除其中THTEMP1的结点

如上图，在PublishAction外部添加了两个操作：

1、使用AssignAction添加了一个名为ctybody的自定义的MessageContextVariable，将$body的值赋予它，以便验证$body的值是否被改变。

2、使用RoutingOptions修改了$outbound的一些属性。

以上操作的目的在于说明PublishAction的内部操作不影响外部操作，PublishAction的作用是接受处理过的RequestMessage，执行其Service并把结果返回给ProxyService，ProxyService可以对最终结果的MessageContextVariable进行处理。

输出：

如上图，为原RequestMessage中的内容。

如上图，此时RequestMessage已被发送到caotyBs2服务，且RequestMessage相比上图少了一个

THTEMP1>结点。

如上图，此时RequestMessage已被发送到caotyBs2服务，查看$outbound中reuqest属性的headers，多了一个自定义的Caoty-Header的header。

如上图，显示的是最终MessageContext的变化。

$ctybody保存的是RequestMessage中$body的值，可以看到虽然在PublishAction中删除了其结点，但在PublishAction外部仍然保持原样。

如上图，可以看到最终$outbound中request属性的headers也恢复了原样。

而且修改了和新添加了一些属性。

Dynamicpublish

将一条message发布（publish）到一个由XQueryExpression表示的Service上

Use

Expression：

XQueryExpression或者是XQueryResource。

其中输入的内容应该形如：

route>

serviceisProxy='false'>{$service}

service>

operation>{$operation}

operation>

route>

说明：

-isProxy表示调用的是否是ProxyService，如果是则为true；否则为false。

-$service输入SerivceName，此处应输入service在ProjectExplorer中的全限定名（thefullyqualifiedservicename）

比如SAP_PS/iS_WS_SAP_ProjectInfoService/WS_SAP_ProjectInfoService_bs

-$operation输入要执行的operation名称，可为空。

operation>结点为可选结点。

AddanAction：

对要发送到Service的Message，添加Action配置如何封装（Package）Message以及如何将Message发送至Service。

Example

输入：

因为Dynamicpublish除了如何指定Service与PublishAction不同，其他原理基本一致，所以这里只展示最一般的情况

如上图，Expression的内容是

route>

serviceisProxy='false'>TEST/caoty_test/business/caotyBs1

service>

route>

表示将Request发布到TEST/caoty_test/business/caotyBs1的BusinessService上，此服务非ProxySerivce并且使用默认的operation。

另外在DynamcipublishAction的内部和外部，不再对Message进行处理。

输出：

如上图所示，RequestMessage被发送至名为caotyBs1的BusinessService服务，并且返回表示成功的ResponseMessage。

PublishTable

发布一条message到多个指定的Services。

通过条件逻辑（Switch-styleconditionlogic）判断运行时发布到哪个Service

PublishTable的使用与RoutingTable的使用类似。

Use

Expression：

XQueryExpression，根据其得到的结果进行条件比较。

Operator比较条件，有=、!

=、<、<=、>、>=几个，后面的空格填入要比较的值（value）。

Service：

选择要Routing到的Service，以及这个Service要执行的Operation（如果选中Useinboundoperationforoutbound，则无需选择，表示这个Service执行与$inbound的operation属性同名的operation）

表示如果上一个条件不满足，则判断当前条件。

表示如果以上所有的条件都不满足，则执行此Default条件

Example

输入：

如上图所示，XQueryExpression解析RequestMessage中的某一结点（此处为ProjectCode），判断其值若为1则Routing至caotyBs1，若为2到caotyBs2，若为其他值到SapPrjNotifyWS_bs；同时这些Service都执行同inbound相同的Operation。

输出：

如上图，发送给Service的RequestMessage的内容如图所示，

ProjectCode>的值为2222。

根据PublishTable的条件，在其不等于1或2的情况下，被发送到名为SapPrjNotifyWS_ps的BusinessService。

Routingoptions

RoutingOptionsAction用来修改$outbound，一个内建（built-in）的消息变量（messagecontextvariable）中的属性（properties），如：

URI，QualityofService，Mode，Retryparameters等（需要了解OSB的MessageContext的相关知识）。

尽管通过Assign、Insert、Replace、Delete对$outbound操作同样可以修改属性，但需要了解XQuery、XPath以及$outbound的结构等知识，Routingoptions提供了一个简单快捷的方法直接修改$outbound的各种属性。

Use

URI：

规定消息（Message）将被发送到的URI，会覆盖outbound中原有的URI。

$outbound中的URI不会被初始化，需要在配置时设定。

QualityofService：

设定发送请求（request）的服务质量（qualityofservice），它将影响事务（transactions）、线程（threading）以及如何处理错误（handerrors）。

分为BestEffort和ExactlyOnce

Mode：

设定CommunicationStyle，是单线（one-way）还是双向（bi-directional），即Request还是Request-Response。

它告诉传输（Transport）是否等待ResponseMessage。

RetryInterval：

设定每次重试（Retry）时间间隔的时长。

RetryCount：

如果传输（Transport）无法将消息（Message）传给URI，设定重试（Retry）的最大次数。

Priority：

用XQueryExpression设定优先度较高的Message。

前提是先Edit一个相应的BusinessService，选择OperationalSettings-Throttling，启用此功能时才有用。

当启用此功能时，将根据Message的priority决定处理先后顺序（通过Routingoptions设定priority），否则使用先进先出顺序，在Throttling中可以通过设置队列最大容量、队列个数、消息过期时限来控制。

Example

输入：

新增的RoutingoptionAction如下所示

修改了其中五个字段，而使用Priority需要先设置Throttling，并且Expression必须是要发送的Message（不过文档没有明确Expression的具体内容，试了几个都报错，所以就没使用Priority）

输出：

当未添加RoutingoptionAction时，消息处理后的$outbound的内容如下

当添加一个RoutingoptionAction后，消息处理后的$outbound的内容如下

通过比较可以看到，URI、Mode、QualityofService被修改，并且新增了RetryCount、RetryInterval两个属性

Servicecallout

配置一个同步的/阻塞的（synchronous/blocking）callout到OSB的一个已注册ProxyService或BusinessService。

callout之前可以对要发送的MessageContent进行处理（通过使用MessageContextVariable构建MessageContent），根据目标服务（TargetService）的类型，进行不同的处理。

目标服务（TargetService）一般有如下几种类型：

1、SOAPDocumentStyleServices

2、SOAPRPCStyleServices

3、XMLService

4、MessagingServices

（注：

在userguide的P78详细说明了在不同的服务类型下，发送给服务的Message是如何构成的并且有具体的示例。

）

Use

Service：

如上图，选择一个ProxyService或BusinessService。

Operation：

如上图，选择完Service后，并选择一个Operation。

如此处必须选择sapPrjNotifyWS。

如上图，当选择一个Operation后，根据Service的类型，会出现如图所示的输入选项，选择ConfigureSoapBody或ConfigurePayloadDocument分别对应不同的输入项。

上图这些输入项的主要作用是：

根据TargetService的类型，构造相应的Message。

Message由以上的输入项构成。

下面分两种情况讨论这些输入项。

ConfigureSoapBody：

配置SOAPBody，可以直接使用$body，可支持SOAPRPCStyleServices类型的目标服务。

如上图所示，SoapRequestBody和SOAPRequestHeader构成RequestMessage（分别作为body和header部分）发送至caotyBs2服务。

SOAPRequestBody：

输入自定义的MessageContextVariable变量