BP SOAP service inbound整理

1. inbound処理はconfirmation messageをoutboundするまでが流れ。

　もしconfirmation serviceをinboundのreciever systemと紐づけてない場合は、srt_moniでDeliveriedと表示されてもデータが反映されない。多分confirmation serviceのoutboundまでしてcommitされると推測。confirmation messageが正しく届くかまでは気にしない。

→　と思ったが、違うっぽい。cl_bs_soa_inappseq_in -> VALIDATE_SEQUENCEで「そのBPすでに変更されたから追加の変更は無視ね。あ、エラーも投げずに成功処理するからしくよろ！」っていう動きが見つかった。えー

→ 検証のやり方が悪い。message idが一緒だからそりゃ受け側は同じメッセージが二回送られたと認識して後できたやつは無視する。でもエラーにするには微妙ーだからDeivelied判定。よく出来てるちゃ出来てるけどこの仕様が分かるまでが大変ー

 

→　犯人は「changeOrdinalNumberValue」。message IDは関係ない。

このような素晴らしいブログがある。

https://blogs.sap.com/2020/03/04/web-service-business-partner-soap-fields-and-explained/

 

　

 

2. https://launchpad.support.sap.com/#/notes/2481529

bgrfcでもsrt_moniでも消せないmessageの消し方。

message terminated後にbgrfcでlock delete。　

 

3. もしconfirmation messageは要らない場合は？

 送り先のシステムがSOAPのinboundをサポートしてない場合、意味ないのでsuitebulkreplicationだけしたい場合は？

 

4. Confirmation送りに失敗したら、対象のBPはさらなる変更を受け取らないことを発見。

   1.の手順でError MessageとQueue lockを削除してもう一度メッセージを送るが、反映されない。

　他のBPを変更したら反映。BPにロックが掛かる？

 

5. bgrfcのdebug -> lock inbound destinaition -> sbgrfcmonで該当queueをdebug。

   inboundの処理クラスはCL_MDG_BP_BUPA_SI_INで、DO_MAPPING_INBOUNDでdebugを掛けておくと

　捕まえる。なかなかruntime処理がつかまらなくて中の処理が全然見えず苦労したけど、

　debugまでは出来たので、後は(時間さえあれば)流れを見てどこでNGになってるかわかると思う。

 

え、ナニコレ。。。前回の変更が終わってない判定になってるし。原因はこれ？

 

https://me.sap.com/notes/0002863972