JDBC Receiver Adatper的同步场景设计

 

转自：http://scnblogs.techweb.com.cn/dario/archives/154.html 请查看原文。

 

在之前的BLOG中，所涉及的都是asynchronous scenario，这次主要会记录一下一个synchronous scenario的细节，其不要不同之处都集中在ESR的设计中，在ID中并无任何不同之处。同时，在很多网上的文章都指出同步场景往往需要使用BPM，其实杀鸡不需要用牛刀，很多时候也是并不需要搬出BPM那么复杂的东西的，至少在这里就不需要。

1.为JDBC receiver定义两个data type和message type

data type和message type 的命名需要遵循以下规则：如果request的名字为A,则相应的response的名字必须为A_response,这是SAP规定死了的。

2.Data Type的具体定义:

其实一切知识都来自于SAP HELP，只不过需要去实际应用取得经验，所以在定义data type之前可以参考一下SAP帮助：http://help.sap.com/saphelp_nw2004s/helpdata/en/0b/9a50465ccf84479e39a6d50c90fb3f/frameset.htm，

https://help.sap.com/doc/saphelp_nwpi711/7.1.1/en-US/4d/8c103e05df2e4b95cbcc68fed61705/content.htm?no_cache=true

其中有这么一段:

<StatementName4>
<dbTableName action=”SELECT”>
<table>realDbTableName</table>
<access>
<col1/>
<col2/>
<col3/>
</access>
<key1>
<col2>val2old</col2>
<col4>val4</col4>
</key1>
<key2>
<col2>val2old2</col2>
</key2>
</dbTableName>

</StatementName4>

这就是我们需要的格式，实际设计截图如下：

JDBC Request:

上图分别包含了两个查询,QUERY_FXJLZ和QUERY_BJCH,VIEW_FXJLZ和VIEW_BJCH是两个要查询的视图名字，action这个属性就会在后面的message mapping中被赋予’SELECT’,access下面需要定义需要被取出来的字段，key下面则定义条件字段。

再来看data type for JDBC response

这里的命名同也有规定，就是需要和前面的request对应，分别在原来的名字后加上_response，这是必需的，不能改变.同时access变成row（下面的字段也要完全一模一样），其他的都不要了，JDBC在取得数据后会自动放到这个结构中间来。

3.Message Mapping的定义

如上图所示，这里定义了一个RFC 到JDBC的request mapping,有不少的地方需要注意：

1.对于key下面的条件字段，每个字段都需要插入一个属性compareOperation(添加属性需要在data type定义时进行)，用来用作where条件中的比较操作符，在上面的参考文档中有一个允许值列表，支持了EQ,NEQ,LT,LTEQ,GT,GTEQ以及LIKE模糊查询。

2.对于access以及access下面的字段，虽然这时候还没有值取出来，但是仍然要如上图一样，赋一个空值常量给access以及access下面的每一个字段，如果不这样做，生成出来的语句就会是:

SELECT FROM dbTableName …..

而不是:

SELECT col1,col2,col3 FROM dbTableName

缺少了目标字段列表,会导致JDBC出错.

上面的这一点非常重要，在SAP的文档中都没有提及（至少我目前没有看到），这一点在之前的IDOC Receiver中也被用到了，切记切记这一点。

3.对于ACTION字段，这里需要输入‘SELECT’.

对于response mapping的定义就比较简单，将取回来的数据对应到RFC response即可，如下图:

4.Operation Mapping

Operation Mapping也比较简单,相比较asnchronous只关联一个message mapping来说，这里会关联两个message mapping，分别为前面定义的request和response。

5.其他方面则和asnchronous场景没有任何差别。