在许多场景中，带有操作执行结果的响应以异步方式传递给操作启动器(SMDP或Operator)。例如SGP.02 v4.2的3.3.1中的步骤(13):
(13) SM-SR应将响应返回给"ES3"。启用SM-DP的"EnableProfile"功能，表示配置文件已启用
如果包含操作结果的调用失败，SMSR应该如何处理尚不清楚。SMSR应该一直重试这样的调用，还是可以只尝试一次，然后放弃?这取决于调用期间发生的错误类型吗?
我关心的情况是，当结果被发送并且可能已经被发起者处理，但是有关该结果的信息没有正确地传递回SMSR。为了要求SMSR重试，启动器应该准备好再次接收相同的操作结果状态，并相应地处理它，即忽略和仅确认。
但是我在SGP02 v4.2中看不到任何指定SMSR和SMDP在这种情况下应该是什么行为的内容。非常感谢任何指向指定此文件的文档的指针。
一般来说，在这种情况下如何回滚到有效的已知状态是不清楚的。谁对此负责(在这个启用概要文件的示例中是SMSR还是SMDP)?
我不知道规范中有任何部分定义了这一点。在SGP.02, SGP.01和测试规范SGP.11中都没有。对于连续服务，SAS认证中有一些操作要求。但这在技术上没有定义。
我有实现规范的经验。该方法是一个带有Kafka和重试策略的消息队列。规范说的是SHALL，意思是非常努力。任何在一次尝试后丢弃消息的实现都不是面向质量的。在基于分布式(微服务)的系统中，常识是存在必须处理的故障，因此这个假设没有在SGP规范中表示。配置文件状态的示例应该是幂等的，发送两次消息应该是无害的。MessageID和RelatesTo在这里也很有用。我假设对于审计，请求/响应无论如何都记录在您的系统中。
如果你坐在另一端，面对一个糟糕的实现SM-SR和nt状态消息到达，ES3。稍后SM-DP可以调用GetEIS来获取当前状态。
我已经直接联系了作者。在文档的末尾提到了电子邮件:
提供优质的产品供您使用是我们的初衷。如果你如有任何错误或遗漏，请与我们联系。您可以通过prd@gsma.com通知我们