sappi的一些常见问题以及解决方法.docxVIP

解答: 这些错误一般由于 XI PIPE LINE 服务UAVALIABLE —般发生在 ADAPTER Engine向 Integration Engine管道发送消息做后续处理时， integration Engine无法响应，解决办法 一般可以查看SICF /default_host/sap/xi/e ngi ne 状态，OK之后重新发送消息（此类 问题经常遇见） 问题2 “ HOLDING message 的解决办法？ 解答： Holding message 发生于QOS为EOIO的场景中，一般由于上一条消息因为 MAPPING错误 或者INBOUND Adapter出现问题导致消息发送失败，这是如果不能及时 CANCELS条失败的 消息，后续同一队列的消息就会被堵在队列中。 所以一般情况下当发生 EOIO类型消息的错误时我们都要在 RWB!面检查是否有HOLDING犬 态的消息，如果有，一定要先把错误消息 CANCELLED^，然后将队列中最早的一条消息 RESTART；可题就可以解决了。 问题3 如何解决Message Mapping错误？ 解答： MESSAGE MAPPIN一般占据了整个 PI运维的错误的80%以上，而且这类错误一般我们在制 度流程中只能CANCELLED^并且通知原系统用户重新发消息 如果正常的情况下 MAPPING匕较简单我们还可以通过 SXI_MONITOR勺ERROROG查出错误的 根源，但是在更为复杂的 mapping当中，我们一般情况下在消息监控 日志中就没办法找到 MAPPING昔误的原因了，这种情况下我们必须通过 ESR的 MAPPINCTEST 机制和相应的DISPLAY QUEUED能去做MAPPING测试，可以激活 MAPPING测试的DEBUGS 别 这样对于GRAPHIC mapping就可以很快找到错误的原因，对于更高级别的 UDF尤其是 COMPLEX mappi ng这种方法不好使，只能在相应的 UDF代码中 打TRACE跟踪程序。 需要提到的是，一般我们不可能在生产系统做 MAPPING TEST由于MAPPING PROGRAM在 ESR里面的，因此用开发系统测试 MAPPING1最好的选择。 问题4 消息已经发到 PI并且在在SXI_MONITOR里面已经MAPPING成功，一切迹象显示消息成功发 送，但是目标系统（ECC并没收到消息 解答： 此类问题出现在目标系统通过 ALE方式接收消息，在这种情况下一般由于消息堵在底层 TRFC 传输层，我遇到的一些情况比如同时大量接收消息 PI内存不够用的情况下，或者目标系统 不可达的情况下，就会出现这种问题 一般这种问题不会通过 RWB勺ALERT机制通知运维工程师，所以当出现这种情况我们需要 在SM58,SMQ1,SMG中分别检查是否有消息堵在队列中并且释放 （手工执行相应的LUW卩可）， 我们可以通过Solution Man ager 的监控功能 来监控SM58,SMQ1,SMQ中的队列状态，或者自己开发 ABAP程序并且 BACKGROUNCHEDULE 也行。 问题5 JDBCADAPTER5ENDE市不POLL消息怎么办，表现出来的迹象就是 Communication Channel 正常，但是很久没有 POLL消息了 解达： 手工重启Communication Channel并且可以利用 PI的ATP机制强制CC每一个小时重启 一一 次。 问题6 当我们改变 SLD的值的时候（比如添加了 SOFTWARE COMPONENT VER）I在NID,IR 里面并 没有更新相应的值 解答： 这种情况下我们应该在 IR或ID里面清空SLD缓存 IR - Menu - Environment - Clear SLD Data Cache ID - Menu - Environment - Clear SLD Data Cache 问题7 （引用SAP SCN乍者原文） RWB打不开或者提示一些权限问题 解答： SU01 - user = XIRWBUSER - Unlock 冋题8 PI ABAP用户和JAVA用户的映射关系 解答： 在PI配置中，最麻烦的莫过于我们需要同时处理两套应用服务器引擎， ABAP和J2EE并且 需要明白他们各自组件的功能和通讯协作机制，因此搞明白 ABAP和J2EE的用户映射机制非常重要， 在PI中,ABAP端的用户帐号-J2EE用户帐号，ABAP 角色-J2EE用户组，另外还有一个东西是 ABAP端没有但是J2EE端 存在的就是J2EE中的用户角色，这部分在 SLD权限管理中很重要，因此一个帐号在 J2EE 有个相应权限组后还需要具备同名的权限，否则就会出现很多权限问题，