问题1:MessageMonitoring(SXI_MONITOR)的ERROR_LOG HTTP_RESP_STATUS_CODE_NOT_OK或者HTTP相关错误?解答:这些错误一般由于XIPIPELINE服务UAVALIABLE,一般发生在ADAPTEREngine向IntegrationEngine管道发送消息做后续处理时,integrationEngine无法响应,解决办法一般可以查看SICF/default_host/sap/xi/engine状态,OK之后重新发送消息(此类问题经常遇见)问题2“HOLDING”message的解决办法?解答:Holdingmessage发生于QOS为EOIO的场景中,一般由于上一条消息因为MAPPING错误或者INBOUNDAdapter出现问题导致消息发送失败,这是如果不能及时CANCEL这条失败的消息,后续同一队列的消息就会被堵在队列中。所以一般情况下当发生EOIO类型消息的错误时我们都要在RWB里面检查是否有HOLDING状态的消息,如果有,一定要先把错误消息CANCELLED掉,然后将队列中最早的一条消息RESTART,问题就可以解决了。问题3如何解决MessageMapping错误?解答:MESSAGEMAPPING一般占据了整个PI运维的错误的80%以上,而且这类错误一般我们在制度流程中只能CANCELLED掉并且通知原系统用户重新发消息如果正常的情况下MAPPING比较简单我们还可以通过SXI_MONITOR的ERRORLOG查出错误的根源,但是在更为复杂的mapping当中,我们一般情况下在消息监控日志中就没办法找到MAPPING错误的原因了,这种情况下我们必须通过ESR的MAPPINGTEST机制和相应的DISPLAYQUEUE功能去做MAPPING测试,可以激活MAPPING测试的DEBUG级别这样对于GRAPHICmapping就可以很快找到错误的原因,PLEXmapping这种方法不好使,只能在相应的UDF代码中打TRACE跟踪程序。需要提到的是,一般我们不可能在生产系统做MAPPINGTEST,由于MAPPINGPROGRAM实在ESR里面的,因此用开发系统测试MAPPING是最好的选择。问题4消息已经发到PI并且在在SXI_MONITOR里面已经MAPPING成功,一切迹象显示消息成功发送,但是目标系统(ECC)并没收到消息解答:此类问题出现在目标系统通过ALE方式接收消息,在这种情况下一般由于消息堵在底层TRFC传输层,我遇到的一些情况比如同时大量接收消息PI内存不够用的情况下,或者目标系统不可达的情况下,就会出现这种问题一般这种问题不会通过RWB的ALERT机制通知运维工程师,所以当出现这种情况我们需要在SM58,SMQ1,SMQ2中分别检查是否有消息堵在队列中并且释放(手工执行相应的LUW即可),我们可以通过SolutionManager的监控功能来监控SM58,SMQ1,SMQ2中的队列状态,或者自己开发ABAP程序并且BACKGROUNDSCHEDULE也行。问题5JDBCADAPTERSENDER方不POLL消息怎么办,municationChannel正常,但是很久没有POLL消息了解达:每一个小时重启一次。问题6当我们改变SLD的值的时候(PONENTVERS
sap+pi+的一些常见问题以及解决方法 来自淘豆网m.daumloan.com转载请标明出处.
