RFC Sender to JDBC receiver scenario中值得注意的三个问题

转自：http://scnblogs.techweb.com.cn/dario/archives/117.html

初看起来这个场景和之前展示过的JDBC2RFC场景差不多，刚好倒过来了，其实在配置方面有很大的不同，这里就在整个开发过程中需要特别注意的地方总结一下，但是不再对全部细节按照先后顺序进行描述,因为其他部分都比较简单，是在任何一个场景都会有的重复性操作.

整个场景是从ECC系统通过PI向ORACLE ERP数据表写数据，我觉得主要的关注点有下面三个地方：

1.配置RFC sender Communication Channel

关于这个问题网上其实有不少的内容可以找到，但是我还没有发现有一个比较全面的介绍，很多东西相信大家如果是第一次做的话也会看的云里雾里，所以还是在这里综合一下这些内容，同时也加上了自己的一些理解，下面是RFC SENDER CHANNEL的截图。






这里的Application Server(Gateway) 和Application Server Service(Gateway)一定是和PI连接的那个ECC系统的Gateway,而不是PI本身的Gateway，这两个参数值可以在ECC的事务代码SMGW里看到。在我们登录ECC系统之后，按照路径SMGW–>Goto–>Parameter–>Display, 然后找到参数gateway hostname和gateway service的值即可。

对于另外一个参数Program ID，同样也会令初学者困扰，因为如果我们在ECC上建立一个TCP/IP连接指向PI时，如果选择了Registered Server Program,并且Gateway Host和Gateway service参数填的都是PI系统的参数值的话，这个Program ID是必须要在PI J2EE Admin工具上的Jco RFC Provider那里注册的，否则就会报错。例如：





（可以通过http://<host>:5<system no>00/webdynpro/dispatcher/sap.com/tc~lm~itsam~ui~mainframe~wd/FloorPlanApp?applicationID=com.sap.itsam.cfg.java.jco&isLocal=true查看Jco RFC provider）

但是在我们这里配置这个Program ID的时候，是不需要去注册的，因为当我们在PI的Integration Builder激活这个communication channel之后，在ECC系统上使用事务代码SMGW,按照路径 Goto–> Logged on clients, 就可以看到这个Program ID 已经出现在了 TP name里面：





这里要注意的是，这个TP对应的那个LU（logical unit）就是PI系统的主机名。当这条记录出现在这里的时候，就证明PI和ECC已经建立了一个TCP/IP连接。

接下来我们就只需要在事务代码SM59中去建立一个RFC Destination指向这个连接。





注意，这个Program ID要和COMMUNICATION CHANNEL中的完全一致包括大小写，同时这里的Gateway Host仍然还是要填写E CC的，其实很简单，记住一条准则，就是所有的这些地方的Gateway Host都要填与PI相连的那个业务系统的。

最后在程序中使用这个RFC Destination:

CALL FUNCTION ‘ZTEST’
IN BACKGROUND TASK
DESTINATION ‘SAP2ORACLE_AP’
TABLES
pt_oracle_ap          = GT_TABLE[]
EXCEPTIONS
system_failure        = 1
communication_failure = 2
OTHERS = 3.


IF sy-subrc <> 0.
MESSAGE e281.
ELSE.

COMMIT WORK.  “触发RFC


ENDIF.

由于是异步的RFC发送，所以在这里应该使用backgroud task 或者background unit方式然后再用CMOOIT WORK触发，如果直接调用会报no_mapping_program_found之类的错误（但是整个场景还是会成功），同时由于这个原因我们也不能直接在SE37里直接测试，在SE37的测试页面只能测试同步的情况。

2. 如果我们在JDBC Receiver channel中的Message Protocol参数选择了“XML SQL Format”，就要求我们在设计DATA TYPE的时候必须遵循一定的格式，详细的内容分可以参考SAP帮助（http://help.sap.com/saphelp_nw2004s/helpdata/en/0b/9a50465ccf84479e39a6d50c90fb3f/frameset.htm），这里给出一个实例：

例如对于一个INSERT一条新的记录到数据库表的操作来讲，标准的格式是：

<root>

<StatementName>

<dbTableName action=”INSERT”>

<table>realDbTableName</table>

<access>

<col1>val1</col1>

<col2>val2</col2>

</access>

</dbTableName>

</StatementName>

</root>

实际中的一个例子如下图：







root和StatementName是可以赋任意的值的，这里就给了ZDT_AP_RCV_001和Oracle_AP,只是便于理解没有其他的含义。但是在CUX_SAP2AP_INTERFACE那个位置就只能填需要被更新的表名字（在这个例子中CUX_SAP2AP_INTERFACE就是表名字）。而且必须带有属性action和元素table,action在MAPPING的时候需要被赋予例如INSERT或者UPDATE之类的SQL命令，而table则需要被赋予需要更新的表名字（这里有两个地方都可以填table名字，后一个主要是为了考虑table name中如果含有XML非法字符的时候用的，不是必需的），access下面则包含了所有的表结构字段。这些格式都是固定的，不能像我们之前那样可以任意定义DATA TYPE.

3.数据库更新中的日期格式问题。

这个问题在JDBC的场景中碰到的几率一般都很高，之前的JDBC SENDER场景就需要将外部数据库的日期格式转换成SAP的格式，而这里呢也需要从SAP转换成ORACLE,DB2的格式，不过这里的问题和解决办法主要只是针对oracle。对于DB2我不是很了解，也没有测试过。

在这个场景中，最开始的几次测试中总是出现ORA-01861: literal does not match format ，ORA-01840: input value not long enough for date之类的数据格式错误，为了解决问题最后就到处搜索，然后就找到了SDN上的一个blog： DATE/TIME datatypes and Oracle Database 可以解决这个格式问题，所以在这里转载一下。

不过略微需要注意的是，SAP的数据格式到了PI上做MAPPING的时候就已经是YYYY-MM-DD了，不再是YYYYMMDD。