“If ignorance is bliss, why aren’t there more happy people?” – unknown source
Continuing on with the Endeavour of the conquest of Rosettanet scenarios with SAP XI/PI, this blog should be the final battle and the end of this war. Well, I know at times ‘metaphors’ can be irritating (forget the war and battle), so let me try to put it straight and simple going forward. 🙂
1. The RSTK is configured on your local machine. ‘Close Encounters’ with the Rosettanet STK
2. A Rosettanet scenario is configured in XI. Rosettanet/RNIF & XI/PI – Breaking the Code
A DESADV.DELVRY03 Idoc is triggered from R3. XI converts it to a PIP3B2 (Advance Shipment Notification) messages and sends it to the RSTK. The RSTK validates the message and replies back with an acknowledgement.
The Testing Procedure –
* Login to the RSTK with the user specified in the receiver communication channel. The user is RNetShipper03 in this case.
* On the main menu, from the drop down select the PIP as 3B2. Select the appropriate Test Scenario. Since I have used the PIP3B2 version V 01.00 and our scenario is the RSTK as the receiver (R3 is the shipper), the test scenario will be 3B2V01.00-AdvanceShipmentNotification-0000-Scenario-Receiver
* Fill in the Global Business ID as the DUNS you have used in your Party (in integration directory) for the respective CUT and Test sections.
* The location will be the same as you have defined in your RNIF adapter
* Since the configuration I have used does not involve any security or the use of certificates, the same is set to none in the STK also.
* By clicking on Submit, the STK loads a scenario where in it would act as a Rosettanet system expecting a PIP3B2 V01.00 to come in. So go ahead and keep the scenario loaded.
* The RSTK will now be waiting for a PIP3B2 from XI to come in so that it can process the same.
* Trigger a DESADV.DELVRY03 from R3 to run the configured scenario in XI. XI’s RNIF receiver adapter processes the message it sends it to STK.
* Once the STK receives the message, it validates mainly the following;
1. Delivery Header
2. Service Header
3. Service Content
* If it is a valid message, the STK triggers back an acknowledgement message (RN-Business Signal) to XI.
The below screenshot shows the status report of a valid PIP send from XI.
Entries in Message Monitoring:
The above screenshot shows the message monitoring entries from the RWB. The entries are in the decending order of the time stamp. If you look into the same you will find that the STK (PIP3B2_V0100_Reciever) responds back with the Ack. ie the business signal.
If we go into the details of that message, it will show us the actual Ack. message and the status.
Some sample screenshots of a failed PIP in STK due to wrong content;
All that’s well, ends well they say ….. the war has ended, the conquest .. errr..umm… That’s it folks !!!