Slow performance executing XPPCMD if userid not logged on
search cancel

Slow performance executing XPPCMD if userid not logged on


Article ID: 274368


Updated On:


XCOM Data Transport - Windows XCOM Data Transport


The XPPCMD post-processing user exit is taking a long time, i.e. 10 seconds, to execute.
It has been found that if the transfer userid is logged on to the receiving partner server the transfer takes less than 2 seconds i.e. the result is much faster if the transfer userid has a session open on the partner server.
Please provide some insight as to why the XPPCMD batch job called from XCOM runs faster when the userid is logged into the partner XCOM server?
This is causing queuing and slow performance for customers.

Also what can be seen from a Process Monitor session is that when XCOM calls XPPCMD it is trying to run this as the client user and not LocalSystem which XCOM is installed as. This appears to cause an additional delay which does not occur when the client user is already logged into the server.


Release : 11.6


The XPPCMD will run under the security context of the transfer userid so the process monitor observation is expected. 
That is covered on the page Create the CA XCOM Batch Interactive Group.
All jobs, scripts, and remote SMTP notifications received by XCOM Transfer are submitted to the operating system by creating a process.
The new process runs in the security context of the user receiving the XCOM transfer that caused the process to be created.
XCOM Data Transport adds an access control entry (ACE) to the window station and desktop to allow the process to interact with the user.
Once the process is complete, the entry point is removed from the window station and desktop.
If the process created by the transfer creates an additional process, this additional process will not have access to the
window station or desktop after XCOM Data Transport has removed the entry control point that is created by the original process.

1. In this case the XPPCMD calls a Java application which is passed the details of the received file.
2. The Java application initialises an SSL session to a messaging server to send the received XCOM file. The SSL initialisation takes place within Java itself (loads keystore file from disk etc).
3. Once the SSL session is initialised, the file is posted to the messaging server for processing.
What has been found is that if the transfer user is not logged into the partner XCOM server then the SSL initialisation step #2 takes 10 seconds.

The difference in running the XPPCMD script with the user logged on or not logged on to the partner XCOM server, is the script being run in the user’s session or in session 0.
The delay can also be reproduced by executing the XPPCMD on the partner server outside of XCOM using the "runas" command, so this is not a XCOM related problem.

To debug this issue outside of XCOM on the partner XCOM server:
a. Logon as the transfer userid, run XPPCMD manually outside of XCOM.
b. Log off the transfer userid and logon as administrator. Use "runas /user:transfer_userid cmd.exe" to start a command prompt and again run XPPCMD manually outside of XCOM.