Shana，你好

根据您的要求，您有几种选择：

1。 使用SAP PI归档 https://archive.sap.com/discussions/thread/3258808

2。 您可以在映射级别使用java映射将数据存储在第三个系统中。

3。 您可以进行多重映射，以有一个额外的接收器来存储数据。

4。 您可以在发送方系统中创建Z表，并将数据存储在响应中。

此致。

嗨，

使用SAP PI归档 https://archive.sap.com/discussions/thread/325

我们可以使此接口特定吗？ 或将整个邮件存档。

我只需要一个接口消息存储。

嗨，Sahana，

在SAP PO中存储如此长时间的已处理消息背后是否有合理的理由？ 这是一个中间件系统，不打算用于这样的长期审核跟踪。 相反，如果对应用程序数据的长期存储有任何法律或业务驱动的要求，则通常由处理该数据的相应应用程序系统（在此为发送方或第三方接收方系统）来处理和满足这些要求。

将此类长期数据存储在PO的数据库中（例如，在自定义表中）违反了其数据库的整个设计和使用，该数据库的设计是轻量级的，而不是用作应用程序数据的存储 。 将此类长期数据存储在PO数据库中的决定的弊端在于数据库规模的增大和相关维护工作的增加。

PO系统中的归档目的地不是特定于接口的，这意味着所有应归档的消息 通过执行的归档作业将，，，，，，，，，，，，，，，，，，，，，，，，，，，的移动到相同的归档目的地。 如果您打算将已归档的PO消息存储3-4年，则可能会大大增加对归档数据存储大小的要求。

如Iñaki所建议的，从技术上讲，可以使用一个额外的接收器系统 与数据存储相关联，将消息发送到该数据存储中以进行长期存储，但是如果主接口成功处理了消息，而用于将消息数据存储在长期存储中的辅助接口出现故障，则会引入潜在的不一致问题。 p>

从映射为长期目的而调用消息数据存储使我提出了一个问题，即如果此功能失败，流程将如何进行？ 它将消息传递到第三方系统时进一步发展（然后第三方系统接收数据，即使它没有长期保存在存储系统中-不一致问题），还是会因错误而失败（然后 长期存储的可用性在很大程度上取决于接口的操作，而向第三方系统的数据传输在很大程度上取决于长期存储的可用性。 此外，除非通过映射异步完成对长期存储的调用，否则还会影响接口性能，因为在与长期存储的同步通信中，PO希望响应消息数据的持久性请求而接收到确认/错误。 在长期存储中，PO必须等待直到收到此类响应，然后才能继续向第三方系统处理消息。

您可以看到，有一些技术选择可以满足这种要求，并且 它们由Iñaki进行了描述，但是如果在PO系统的顶部实施，它们全都将技术债务引入解决方案或影响运行时/性能。

问候

Vadim

你好IñakiVila / Vadim Klimov

请在此线程上输入您的宝贵建议。

https://answers.sap.com/questions/12882619/how-to-store-and-retrieve-oauth-tokens-in-sap-po.html

非常感谢！

关于– Rajesh PS

您可以在PI JAVA Stack中创建AS JAVA表并使用它。

有CAF（复合应用程序框架）的概念 。 您也可以对此进行探索。

谢谢

Apu