SAP最近发布了Solution Manager 7.2的SP4，它主要是一个纠正性的SP。这似乎是一个足够好的版本，可以尝试Solman（千万不要使用Solman访问第一个SP…）。直接转到SP4可以节省很多时间，因为它包含了所有最新的OSS注释，所以手动应用的注释更少。请注意，7.2 SP4也是VAR场景的第一个版本（针对SAP合作伙伴）。

Solution Manager 7.2现在基于Netweaver 7.4（终于…），不再是双堆栈系统。在过去，客户倾向于我们索尔曼只为MOPZ（维护优化器），自助免费建站，我认为这是一个有点浪费。凭借SAP在Solution Manager中推出的所有功能，客户逐渐意识到Solman可以带来很多价值（正确实施时），云 服务器，因此需要维护4个额外的SAP系统（一个Solman ABAP，一个Solman Java，x2（用于开发和生产）不是一个值得证明的问题。

7.2中ABAP和Java之间的功能划分似乎类似于7.1，因此Java堆栈主要处理与各种代理的通信。由于java堆栈保持连接对所有代理开放，因此对于中等规模（>50个系统），您应该调整java作为参数。对于大型环境（>200个系统），需要额外的Java应用服务器。一般来说，我建议至少有两个应用服务器（中央实例算一个as）以实现高可用性。

ABAP堆栈可能会因要监视的系统数量而负载过重。您可以按照快速尺码器了解更多细节。只有几个提示：

像服务台和Charm（变更请求管理）这样的场景不会导致很重的负载（但是需要一个强大的CPU，参见下文）解决方案文档可能需要数据库中的大量空间，因为最终用户可以在那里存储文件。监控（尤其是技术监控）将很快要求您添加应用程序服务器，因为SAP每分钟都会收集大量数据。SAP确实在solman7.1sp10/12中引入了度量收集/处理的并行化，物联网技术，但这还不够。如果您计划监视许多系统，您必须准备添加应用程序服务器。

如果您有可用的资源（硬件和dba知识），HANA绝对是推荐的，因为这是SAP的参考数据库。SAP还为您提供了运行Solman的免费HANA许可证。

下面是一个调整Linux虚拟机大小的示例，以实现高可用性，并能够在50系统环境中处理一些场景。更多细节请参考快速尺码器。

请注意，如果您打算使用Charm或ITSM，则需要注意CPU的功率。这是因为这些场景都是基于CRM的，CRM非常繁重（SRM也有同样的问题）。注1501701-单计算单元性能和大小记录了这一点，在quicksizer中，场景Charm和ITSM（都构建在CRM之上）因此被归类为AAA级（SCU级）（得益于强大的CPU）。如果您不打算使用Charm或ITSM，那么您就不需要注意这一点。这只是部署的一个例子，对于HA来说，它能够支持多达100个托管系统。没有提供实际拥有HA或DR的详细信息，因为它们取决于您的基础设施。

有一个单独的中央SLD是可选的，但在大环境中更干净，联网，特别是如果您需要合并来自美洲、欧洲、中东和非洲等地的技术数据，这些数据可以单独管理。否则，使用PI/PO SLD也可以。

Solman 7.2支持最新安装。安装本身没有任何特殊之处，人工智能研究，只需安装ABAP堆栈，然后安装Java堆栈。Java堆栈将使用ABAP堆栈进行UME（用户管理）。然后为每台服务器安装Wily和一个诊断代理DAA/98。

然后继续升级。有些软件包，比如SAPUI750，相当大。您可以进行单次系统升级，以避免浪费创建影子数据库的时间。ABAP升级部分在一个有3个R3load进程的小型服务器上需要约24小时。

我喜欢使用客户端100，所以我将其创建为客户端001的SAP\u ALL副本，但这不是强制性的。

在SOLMAN\u安装过程中，我很高兴看到SAP建议使用Solution Manager开发系统，并从中传输用户角色和更正。这是我强烈建议的，因为你将有问题与Solman和你将需要应用OSS笔记，你将需要测试。当你有100多名开发人员不能再工作时，打破生产的魅力是不好的。因此，您至少需要一个开发系统，如果可能的话，还需要一个质量/测试系统。

我也很高兴在SM50中再次看到我的老朋友LMDB\u P\u实例…如果您在SOLMAN\u设置中有一些步骤需要LMDB数据并且需要很长时间，请确保LMDB表的统计数据是最新的。请参阅注释1829335–solman\u安装期间先决条件检查阶段性能缓慢或超时–SAP ASE for Business Suite

2393893–Solution Manager 7.2 SP Stack 04：建议更正2334291–SAP Solution Manager 7.2支持包04–基本功能