One Moment with Communication Station 5.0 Whenever we want to understand something, we will start up with the below questions.
What? Why? & How?
And when we believe that we do understand something, the question will be
Why not?
So as we try to know about Communication Station 5.0, we will follow the above tradition and let’s see if we can find the answers. And for those who simply want the answer for the last question, you can directly read the last section of this blog to know the answer.
WHAT is Communication Station 5.0?
Communication Station (hence will be called CommStation, to save a few keystrokes), is a Windows system to which the CRM Mobile client (MSA/MSE/MSY Laptop solution for Windows) connects to, whenever it needs data to be ‘communicated’ to the CRM server. The Mobile client will conveniently talk to the CommStation, a machine which is ‘similar’ to itself, in terms of technology. Such a scenario will efficiently serve the purpose of the Mobile client online-offline solution, the details of which will be explained in ‘How?’.
WHY CommStation?
We saw that CommStation will talk to CRM server and that Mobile client is ‘similar’ in terms of technology. Then why can’t we make the Mobile client talk to CRM server instead of investing in CommStation? Good question for a developer but not so good one for an architect though.
Imagine thousands of Mobile clients (even hundreds) of Mobile clients trying to establish their authenticity (from different networks and from remote places) to the CRM server. There are firewalls and other network jargons in between which are obvious challenges before the direct communication could be possible. If that’s not enough, imagine the CRM server manage the connections from those Mobile clients, send and receive enterprise data (after authentication) and also ensure the resources used for those connections are properly disposed off after the session is over. The Communication session could be over when the ‘protocol’ is properly completed or it could be over as soon as the MSA user pulls the plug.
So we are now talking about a ‘could-be-unpredictable’ usage scenario and we need something to have a control on this. That ‘something’ is the CommStation. CommStation authenticates the genuineness of the Mobile client and further helps it to establish the authentication to the CRM server. It also helps manage the connection resources at the CRM server even at times when the Mobile clients go unpredictable.
HOW the CommStation does what it does?
The CommStation is a stationary system which can connect to the CRM server 'whenever' it wants to(always connected). It can also connect to Multiple CRM destinations at the same time. The CRM destination to which the CommStation (and thereby the Mobile client) should connect has to be configured with the ‘Destinations’ section of the QmtCnfg.exe tool at the CommStation.
CommStation has to authenticate the Mobile client if it is a legitimate machine in the network. Mobile clients keep moving and so this check is extremely important. The check is inherent in the COM+ technology used in connecting the Mobile client to the CommStation. For the details on how this is inherent, you could check the Microsoft pages on COM+ technology . You could also check with a sample COM+ application, which you can use to identify the values of the configurable network parameters to be in place at the Mobile client for it to reach the CommStation.
When you check the connection from Mobile client with QmtCnfg.exe tool, there are two checks done 1) the inherent COM+ check and 2) the Connection check from CommStation to CRM server to which the Mobile client tries to connect.
If both the checks are successful, you are ready to go with the data transfer using ConnTrans.exe provided you have a site assigned to the Mobile client. When ConnTrans.exe starts the data transfer, it tries to authenticate the DBID to the CRM server. The DBID is the token of authentication between the CRM server and the Mobile client, shared at the time of site assignment using ClientConsole.exe .
Whenever ConnTrans.exe is run or whenever the QmtCnfg.exe is used to test connection, CommStation is contacted, which triggers the CommStation application. Since the CommStation application (SAP CRM Mobile Transfer 5.0) is registered as a COM+ service, Windows system hosts the application in a separate process called dllhost.exe. If there is a large number of Mobile clients each trying to make use of the dllhost.exe process, it might lead to performance issues with a single dllhost.exe process. Microsoft Windows Server 2003 and Microsoft Windows XP systems have come up with enhanced performance making use of "Application Pooling". To know how to make use of this, please see Note 1255658 .
WHY are the MSA users NOT able to do the data transfer?
The first answer to this is “we have to find out”. QmtCnfg.exe is the first savior and we have to check if there are any errors in any of the two checks done at the Mobile client that we discussed earlier.
If the first check is not successful, then we need to have a look at the network parameters (configured using dcomcnfg.exe for SAP CRM Mobile Transfer Service). The sample application here will help you identify if the DCOM is indeed enabled between the Mobile client and CommStation.
If the second check, the check from CommStation to the CRM server, is not successful, we have to see whether the destination specified at the Mobile client is configured at the CommStation and also reachable from the CommStation (by using QmtCnfg.exe at the CommStation). If no specific destination is configured at the Mobile client, it will connect to the destination which is configured as ‘Default’ at the CommStation.
Both the checks are successful and the MSA user also is able to do the data transfer but often faces trouble in the middle of the transfer. You go crazy about what is happening. But no need to worry, the CommStation has ‘site-specific’ logs and one site-independent log maintained at the Windows Event Viewer. These provide valuable information about what is done at every step. The ‘site-specific’ logs can be identified by the right-substring of the corresponding CRM server queue names.
There might be moments when none of the Mobile clients are able to reach the CommStation. The reason could be ranging from updates run on the CommStation system, tampered Registry etc. At such times, the site-independent logs with the name ‘SAP CRM Mobile Transfer 5.0’ will come handy.
Note 1036377 is a HOTFIX for the CommStation system. Note 1022089 and Note 1255658 are important consulting notes for your serious consideration.
Things you must know if you are CommStation admin:
- Whenever you are asked to register the CommStation COM+ application manually, you need to use the Regsvcs.exe of the ‘correct’ .NET framework. .NET 1.1 if you are on SAP CRM MSA 5.0 SP00 to SP08 and .NET 2.0 for SAP CRM MSA 5.0 SP09 and above.
- If you are running the COM+ application as a Windows NT service , make sure you uncheck and recheck the 'Run as NT Service' checkbox after applying every patch so that the old service is removed and a new service is generated for the patch applied. If this is not done, the old Windows service without the patch will continue to run and the new patch will not have any effect.
- The good old question: Will a 64-bit Windows system give an improved performance as a CommStation? The answer, which might surprise somebody, is NO. A 64-bit Windows system is as good as a 32-bit Windows system for the 32-bit CommStation COM+ application. But yes, the 32-bit CommStation COM+ application is compatible with 64-bit systems as specified in the Notes 1131463 and 1241004. Compatibility and Performance gains are two different things and to get the real performance gain we need a 64-bit application which makes use of 64-bit hardware, which CommStation COM+ application is not.
