Discrepancies after deploying SAP-XI3RDPARTY on different XI systems

[Former Member]

Dear all,

a good basis colleague of my asked me for some XI support on AS Java 7.31 SP7, unfortunately I wasnt able to help him, since Im indeed working on AS Java, but mainly on EP. The problem is as following: my colleague has installed AAE on several JAVA systems in the same manner, but it seems they have discrepancies regardless same installation procedure. In fact we are missing sc-sap-xi3rdparty content on one of them, please see attached screenshots. The first one contains the missed content package.

We saw already this thread here, which seems to describe a similar problem: http://scn.sap.com/thread/3317656, but Im not sure its comparable to our problem, the description says the stuff was not deployed at all. Does anybody now why we have this differences and whats to do to bring both systems on sonsistently status? If you need any further informations, please dont hesitate to ask. Thank you very much in advance,

regards

[Former Member · Accepted solution]

Hello,

I was just working on the same problem. 🙂

I found SAP note 1401570 saying that the other three are contained in xi3rdparty. Maybe that helps you.

Regards,

Jörg

[Former Member · Accepted solution]

Hi Jörg,

thank you, but I already read this one, following linked thread. This SAP note says in fact that version of this components will not be changed. This makes it impossible for JSPM to deploy that stuff, if you are not using "force" mode. The runtime behaviour is quite normal and I already was confronted with this on my own on AS Java. Also, we are not missing the other three, which seems to be functional library components, but the mentioned content stuff. We know they are included in SAPXI3RDPARTY.SCA, since we see appropriate output from deployment script, the question is more where the content package is coming from. In EP context such packages containes normally content like PCD objects, I have no idea what could be comparable content for XI systems. As far I got it there must be wrappers included, I guess this one is probably needed for full functionality. So under these circumstances the 1401570 unfortunately does not helps at all, but thank you for your effort.

regards

[Former Member · Accepted solution]

Jörg, just to keep you on news: meanwhile I had tryed a redeployment for SAPXI3RDPARTY07_0-10009499.SCA and we found some things out:

1.)you cant undeploy content of this package while runtime, since there are many and deep dependencies to other packages. If I stop the AS, telnet funcionality at port 5xxx8 isnt

available

2.)JSPM with force deployment option is not working at all, the tool is moaning no component is selected for deployment, although the package is detected on previous screen. This is mentioned in the note 1401570, but I gave it a try anyway just to see what happens

3.)Since there is no undeployment shell script under .../deployment/scripts/... and the appropriate deploy script is not offering a replace option, as far I got it right, it doesnt help also.

4.)You could try it with ant, special its offering options like <sapundeploy undeploystrategy="IfDependingStop">, Im not sure if its also works for cascaded dependencies. (I also tryed with NWDS, but this machine is on wrong subnet and AS Java isnt reachable at all) But I didnt tryed ant, since:

5.)Instead I extracted sc~sap-xi3rdparty.sda explicit and deployed it with the telnet connection on the machine where we missed it. It wasnt a problem at all, I didnt face any error messages or problems while doing this. Afterwards I controlled the System Components of appropriate machine and voila, it was there.

We have now what we wanted to, namely the same stand of software components in our landscape on all AS Java, but this of course dont explains the anomaly. In fact the question here is: why does explicit deploying of sc~sap-xi3rdparty.sda worked well, while implicit deployment with SAPXI3RDPARTY07_0-10009499.SCA failed without any visible symptoms. Complicating regarding this case is also, as I already mentioned, we didnt had this behavior on all involved Java stacks.

I will close the OSS, since we have found a workaround, but I suppose this is a product error, that need to be corrected. I asked SAP many times for possible reasons, but I didnt got a definite answer, I guess they simply dont know.

regards

[marksmyth · Accepted solution]

Hello

The SAPXI3RDPARTY.sca is an empty wrapper used for third party drivers (e.g. for PI JMS/JDBC/AXIS Adapter integrations). Depending on the customer requirements drivers will be uploaded to this sca (as per note 1138877 How to Deploy External Drivers JDBC/JMS Adapters)

It is not designed to be updated. If it is updated in the normal manner to the other Software Components it is possible that the existing drivers in here will be wiped and the PI interfaces etc will not work.

It is designed for a one time deployment (when the system is first installed). There is no technical requirement for the SAPXI3RDPARTY.sca to be at the same SP release as the other Software Components.

See the notes below for more info:

1. 1401570 PI Upgrade: SAP-XI3RDPARTY SC Version not updated
2. 1634201 PI Upgrade: How to EHP Upgrade external drivers
3. 1335523 FAQ: Deployment PI Patches in Release 7.1 and higher

Regards

Mark

[Former Member · Accepted solution]

Hi Mark,

thank you for your effort on clarification regarding this problem. Unfortunately, my question why we had discrepancies on deployed content is still open. I got already same clues from your colleagues in the OSS I opened.

It is not designed to be updated....
It is designed for a one time deployment (when the system is first installed)

Thats our case, we dont wanted to update this component, the quest was to pass an initial installation on several machines in the landscape and to have same results on all of them. I have read the 1401570 and I understood since there is no versioning mechanism on this component, it cant be updated on conventional way via JSPM.

But this in fact doesnt answer my question. I would like to know:

 In fact the question here is: why does explicit deploying of sc~sap-xi3rdparty.sda worked well, while implicit deployment with SAPXI3RDPARTY07_0-10009499.SCA failed without any visible symptoms. Complicating regarding this case is also, as I already mentioned, we didnt had this behavior on all involved Java stacks.

General, I didnt knew the deployment script, my colleagues used to deploy mentioned component according to 1401570, is just able to skip included sda's without notifying the operator. As I wrote, we also didnt had the same runtime behaviour on all AS. If that would be the case and the deploy script would skip sc~sap-xi3rdparty.sda on all of them, we probably would never realize things are going wrong.

To say it in a simple way: if an operator is installing several instances of a SAP system on same manner and using same directives, he is expecting same results resp. identical stand of deployed packages. If its not the case, either the operator is doing something wrong, or its an error in the product. I didnt found any clues my colleagues had done something wrong, and I also didnt got any clues through the OSS under which circumstances such a deployment can go wrong. So I was able to eliminate the discrepancies, but Im still in the dark about the reasons. Thank you anyway,

regards