读取 IDOC 时如何控制事务(提交/回滚)
当使用 JCo (3.x) 读取从 SAP 服务器发送的 IDOC 时,应采取什么操作来指示消息已被正确接收(即提交)?
在Java中,我想象这样的事情:
public class MyHandler implements JCoIDocHandler {
public void handleRequest(JCoServerContext serverCtx, IDocDocumentList documentList) {
IDocDocumentIterator iterator = documentList.iterator();
while (iterator.hasNext()) {
IDocDocument doc = iterator.next();
// some processing
}
// here I would like to say COMMIT
// i.e., I confirm all the documents have been read
// and our side takes ownership
}
}
如果我们想确保没有消息(IDOC)丢失,即使子弹在某些 .hasNext()
调用期间击中了CPU,这种类型的提交似乎是必要的。还是我错了?
When using JCo (3.x) to read IDOCs sent from a SAP server, what action should be taken to indicate the message has been properly received (i.e. commit)?
In Java I imagine something like:
public class MyHandler implements JCoIDocHandler {
public void handleRequest(JCoServerContext serverCtx, IDocDocumentList documentList) {
IDocDocumentIterator iterator = documentList.iterator();
while (iterator.hasNext()) {
IDocDocument doc = iterator.next();
// some processing
}
// here I would like to say COMMIT
// i.e., I confirm all the documents have been read
// and our side takes ownership
}
}
This type of commit seems necessary if we want to make sure no message (IDOC) is lost, even if a bullet hits the CPU during some .hasNext()
call. Or am I wrong?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在这种情况下,SAP 假定您发回类型为“ALEAUD”的 IDOC。在这种情况下,发送方系统可以将 IDOC 状态更改为“在接收系统中创建的文档”(41)。
有关更多详细信息,请参阅“实施 SAP R/3 的应用程序链接分析 (ALE) 的高级指南”文档
In such cases SAP assumes that you send back IDOC with type of 'ALEAUD'. In this case sender system can change IDOCs statuses to 'document created in receiving system' (41).
For more details look into "The advance Guide to inplementing SAP R/3's Application Link Anabling (ALE)" document
从技术角度(而不是从具有 IDoc 状态记录的业务数据工作流的角度)来看,提交和确认事务性 RFC (tRfc) 的 TID 是 RFC 客户端的任务。在这种情况下,通过接收 IDoc,您的 JCo 程序就是 RFC 服务器,您应该对 RFC 客户端发送给您的提交、回滚和确认事件做出反应。这是通过实现 JCoServerTIDHandler 接口来完成的。
如果您从 handleRequest 调用中返回且没有异常,您将收到一个 commit 事件,稍后还会收到一个 confirmTID 事件,否则您将收到 confirmTID 事件。 em>rollback 以及一个用于做出相应反应的 confirmTID 事件。
From the technical perspective (and not from the perspective of the business data workflow with the IDoc status records) committing and confirming TIDs of a transactional RFC (tRfc) is the task of the RFC client. With receiving IDocs your JCo program is the RFC server in this scenario and you should react on those commit, rollback and confirm events that the RFC client sends to you. This is done by implementing the interface
JCoServerTIDHandler
.You will get a commit and later also a confirmTID event, if you return from your handleRequest invocation without an exception, otherwise you will get a rollback and also a confirmTID event for reacting accordingly.