简介

圆周率（在它的各种名称和形式）已经演变和变化，在过去十年左右，它一直存在。每个SP、EHP和版本都引入了新的功能和增强功能。然而，尽管发生了所有这些变化，一些过时、过时、过时或不再相关的技术和功能今天仍然被广泛使用。其中一个特性是邮件适配器中使用的邮件包特性。如sapnote856599所述，这是一个不推荐使用的特性，不应用于新的场景。以下是注释本身的摘录：

邮件包的使用增加了开发的复杂性，大数据核心，特别是当邮件收件人适配器需要生成带有正文和附件的电子邮件时。这需要使用Java映射或UDF手动构建MIME流。

过去，即使没有邮件包，也建议为上述场景构建MIME流，如Stefan Grube的博客Create email with body and attachments for binary payload with Java mapping中所述。每当论坛中出现这样一个要求的帖子时，我都会反复指向那个博客。

最近，随着瓦迪姆·克里莫夫博客中详细介绍的调试PI应用程序的功能的可用性，淘客公众号，让我们调试吧！在sapplicationserverjava中进行动态调试和反编译，我已经设法进一步了解了邮件适配器的行为。显然，我之前的理解是不正确的，在不使用邮件包的情况下，可以大大简化邮件接收器适配器的场景。

在本文中，我将分享在最常用的场景中使用不使用邮件包的邮件接收器适配器时所需的设计和配置。所有这些场景都使用XIPAYLOAD作为消息协议。

场景1–仅带附件的邮件

第一个场景是最简单的场景，其中主有效负载作为邮件中的附件发送。邮件正文中将没有内容。这是邮件适配器的默认行为。

场景是SFTP到mail iFlow。为简单起见，不包括SFTP信道的配置。

a）将主有效负载的原始文件名保留为附件

邮件接收器信道配置为如下所示：-

i）使用邮件包–未选中

ii）保留附件–已选中

内容编码的值为可选，因此保留为默认值base64.

以下是SFTP发送方通道拾取的测试文件。

收到的电子邮件将该文件作为附件。

附件的名称根据输入的文件名动态确定。即使在SFTP发送方通道上没有设置ASMA，这也是正确的。这是因为文件名存储在SOAP信封附件的MIME头（内容配置和内容描述）中，如下所示。

b）将主负载的命名固定为附件

如果附件名需要静态固定为某个值，这可以通过如下所示使用MessageTransformBean设置以下MIME头来实现。

需要设置所有三个头的原因是由于不同邮件客户端的行为不同。这在问题"如何设置邮件附件的文件名"中作了进一步解释在简介部分提到的SAP注释中，

c）将主有效负载动态重命名为附件

另外，如果需要动态重命名主有效负载，上述方法可以在下面的文章

SetMailAttachmentNameBean–为主负载设置动态附件名称

场景2–仅带正文的邮件

中进行扩展。对于这种场景，什么叫云服务，主负载将用作电子邮件正文。电子邮件中不会有附件。

为此，频道设置与上述类似。

为了将主负载设置为主体，我们需要更改MIME头的内容类型和内容配置。这可以通过以下配置使用MessageTransformBean来完成。

前面测试文件的内容稍微修改如下。

下面是收到的电子邮件。

场景3-带有正文和附件的邮件

最后，我们将构造一个带有正文和附件的电子邮件。在过去，这是最复杂的场景，无论是否使用邮件包，都需要MIME构造。此外，如果内容是二进制的，则需要用Base64编码。

但是，现在可以用场景2中完全相同的配置轻松实现。此外，对于这个场景，云服务器和服务器，还将包括一个Java映射，通过动态配置动态设置Email to和Subject ASMA值。因此，在通道中配置虚拟值。

为了模拟带有附件的消息，SFTP发送者通道得到增强，以获取附加文件、PDF文件和Excel文件。

使用ESR中的直接写入Java映射包含以下逻辑！技术。综上所述，它只是对主负载内容进行一次传递，并动态更新THeaderTO和THeaderSUBJECT的值

文件上传到SFTP服务器上进行提取

在消息监视器中，我们可以看到消息中包含了主负载和两个附件

经过Java映射后最后我们收到了邮件，贵阳大数据，邮件的正文和附件（以及它们的名字）都完好无损。此外，email to和subject中填充了动态确定的值。

结论

如上所示，我们不再需要借助自定义Java逻辑来生成各种场景的电子邮件内容。通过避免使用不推荐使用的邮件包，现在可以（至少从po7.4sp08开始）通过配置以及标准MessageTransformBean模块的帮助来实现各种邮件场景。这将大大减少此类场景的开发工作量。