R3系统中执行RFC导致ccBPM堵塞

lionsir1

   在WAS 6.20(没有安装APPINT add-on)之前版本的系统，我们无法使用Proxy interface，不得不使用RFC interface。
   使用RFC往XI发送消息的代码类似如下：
CALL FUNCTION 'Z_RFC_ORGANIZATION_1'
     IN BACKGROUND TASK DESTINATION 'RFC_SENDER'
EXPORTING
   ZIF_LSH = ZIF_LSH
  TABLES
    ZMM002 = it_zmm002.
COMMIT WORK.
其中'RFC_SENDER'是一个TCP/IP类型的RFC，ZIF_LSH和it_zmm002是需要传送给XI的数据。
  在ccBPM中，发送RFC请求时，有时为了提高系统性能，我们会考虑使用两个异步的消息传输代替一个同步的消息传输，我们通常在ccBPM中放置一个Send Node和一个Receive Node(都是异步的),Send Node发送RFC请求，Receive Node接收RFC返回的消息。
  如上所述的ccBPM开发完成后，正常使用过程中没有任何问题，但如果有人在R3系统中执行了RFC程序（如通过SE37）,这时RFC程序也会向XI发送消息，而且是发向ccBPM，但由于并没有接收这条RFC消息的ccBPM实例，于是导致了ccBPM队列出现错误，通过SMQ2可以查看到如下错误：
"Permanent error in BPE inbound processing"
   应用用户在不知晓的情况下，照常执行ccBPM，会发现无法生成ccBPM实例，消息成功发送到ccBPM后，流程就停止不动了，通过SMQ2，会发现队列问题。
   XI系统管理员可以通过删除错误的条目，然后unlock queue，再restart停止的条目可以解决这个问题，但要想彻底避免发生可以修改RFC程序，将COMMIT WORK注释掉，通过ccBPM去调用RFC时，调用结束后会自动COMMIT WORK的，代码修改如下所示：
CALL FUNCTION 'Z_RFC_ORGANIZATION_1'
     IN BACKGROUND TASK DESTINATION 'RFC_SENDER'
EXPORTING
   ZIF_LSH = ZIF_LSH
  TABLES
    ZMM002 = it_zmm002.
* COMMIT WORK.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/109665/showart_2146046.html