ORACLE企业总线OSB之MessageFlow开发参考.docx
- 文档编号:26251398
- 上传时间:2023-06-17
- 格式:DOCX
- 页数:32
- 大小:33.17KB
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中删除了其 如上图,可以看到最终$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变量
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ORACLE 企业 总线 OSB MessageFlow 开发 参考
![提示](https://static.bdocx.com/images/bang_tan.gif)