One Moment with ConnTrans 5.0

[former_member204283]

*Note : *This blog does not and will not have any help on ConnTrans with images nor will it have any such illustrations. The idea and hope is to have the reader actively participate, understand and appreciate how this killer of a tool called 'ConnTrans' is fundamentally different from what anybody will see in a connected ABAP environment and why this tool which works in occasionally connected environment, needs a different approach of problem solving, if something needs to be fixed.

      When you ask any CRM Mobile Sales stakeholder for the simplest but yet the most intuitive of UIs, the finger would point to ConnTrans , the life-line for the data in a CRM Mobile sales laptop. But I can hear you grinding your teeth because every Mobile Sales user’s nightmare is also the ConnTrans, rather a non-working ConnTrans. This is because one might feel disconnected if ConnTrans isn’t working for any reason which we will discuss further.

      Now I know you are happy that I admitted the truth but the truth is really that ConnTrans is very important for the daily use of the MSA Laptop. Why ConnTrans isn’t working, because it was working just a week before, a day before, an hour before or even a minute before, is often the question which none of the MSA administrators would like to hear.

      Before we go ahead with troubleshooting & solutions, we will try to understand the problem first. The problem here is, of course, ConnTrans. We all know that there are three processing phases in ConnTrans – SEND, RECEIVE and IMPORT. Yes, it’s not any new information because that’s what the UI shows. But sometimes, the MSA users are not lucky enough to even see that UI, because of ‘Initialization failure’. So here is one more phase in which ConnTrans can betray you, INITIALIZATION phase. If that’s not enough, sometimes ConnTrans may not bid a happy bye-bye, when it closes. So that adds to five phases, including the FINAL phase of disposing the objects.

      Meanwhile, we should be devoting some time to the big brother for successful data transfer – Communication Station and the sister tools of ConnTrans namely, *ClientConsole.exe* and QmtCnfg.exe.

      Communication Station serves two main purposes, authentication and connection pooling. Authentication is to make sure if the Mobile Sales laptop which is trying to connect to it, is indeed a legitimate machine in its network. Connection pooling is to balance the load on the CRM server by connecting each communicating laptop to one connection from the available pool of connections in the CRM server. If you could realize, the CRM server does not even know that the Mobile laptops are connecting to it. It knows only that there are sites of type SMW1 and there are queues for such sites. CRM server just puts the data in those server outbound queues and the job ends just there for it. Every data transfer is initiated from the MSA Laptop via ConnTrans and Communication Station. For those who need an analogy, I would mention Microsoft Outlook, arguably the best online-offline solution. You have a data profile (site) maintained at the Microsoft Exchange server (CRM server) and whenever you open Outlook (ConnTrans) you initiate a data transfer with the Exchange server (CRM server).

      The connection from Mobile sales laptop to the Communication station is based on the Microsoft COM+architecture. From the Communication station to the CRM server, it is via the SAP.NET connector . The Authentication for the first level of communication, from Laptop to CommStation is inherent in Microsoft’s COM+ architecture. The Authentication in the second level from CommStation to CRM server is with the user id and password maintained for the CRM destination configured under the ‘Destinations’ in CommStation. This means that you can use the same CommStation for communicating with multiple CRM servers, provided you maintain separate destinations for each of them at the CommStation. One destination is always marked as a DEFAULT destination but the laptop can choose to talk to a particular CRM destination by specifying it in QmtCnfg.exe instead of       There are often questions about how much a CommStation can manage if there are a lot of Mobile clients doing sync at the same time. It purely depends on the capabilities of the CommStation hardware and the ability of the CommStation application to make use of that hardware efficiently. There is often a misconception that a 64-bit system will be the panacea. The truth is a 64-bit Windows system is as good or as bad as a 32-bit system if the software running on it is 32-bit. In our case, CommStation is still a 32-bit software and loading it on a 64-bit system is of no help at all. And yes, there is no harm in having a 64-bit system though, if you can afford it because CommStation is fully compatible with 64-bit architecture (Intel Xeon 64 Bit Platform is not supported officially, since we faced a few problems when testing it). There is some good news in the 32-bit Windows COM+ architecture though. Windows XP and Windows Server 2003 have a capability called "Application Pooling" which you can leverage on to take the maximum out of CommStation. Note 1255658 will be of tremendous help here.

      *ClientConsole.exe* is a tool to link a laptop to the CRM server by assigning a site, to maintain the metadata for the data transfer from CRM to Laptop and also to maintain the table structure in synch with the CRM server’s CDB database.

      QmtCnfg.exe is a simple tool which enables you to check if the Mobile sales laptop is able to reach the Communication station and thereby reach the CRM server destination. It is also the tool used to configure CRM destinations at CommStation. Please refrain from using 'Test Adapter functionality' of ClientConsole.exe. It is made obsolete and is requested to always use QmtCnfg.exe.

      Lets us have some assumptions now before we continue with ConnTrans. The assumptions are:

Dcomcnfg

Navigate to My Computer -> COM+ applications -> SAP CRM Mobile Transfer 5.0

If you are not able to locate it, you may need to perform COM+ registration of MsgTransServer.dll with Regsvcs.exe tool of .NET Framework. Regsvcs.exe is a .NET tool to register an application into COM+. But remember to choose the Regsvcs.exe from the correct framework. .NET 1.1.4322 for 5.0 SP00 to SP08. .NET 2.0.50727 for 5.0 SP09 and above.

Also, Note 1036377 should help here if it applies to you.

You have configured the CommStation hostname or IP address in the QmtCnfg.exe tool at the Mobile Client. The test connection from Mobile Client is successful in both the steps (2 levels of Authentication that we were talking about: Laptop to CommStation & CommStation to CRM server). If not, you may need to check Note 1022089.

At last, we are all set to go through ConnTrans phase by phase.

Initialization Phase of ConnTrans:

The log file for this phase is "ConnTrans_log.xml" which you could normally find in %temp%\ConnTrans folder.

The below is what you could check if the ConnTrans cannot initialize, going again from trivial to catastrophic situation; the log file will guide you in choosing which of the below steps would help you.

1. This could look like a stupid question but some times valid. Did you assign a site to this laptop?
2. You could check if the transfer services are configured correctly in SMO5* tables. If you have any doubt on that, you could regenerate Middleware tables with the ClientConsole.exe (All you need to do is, open ClientConsole.exe and go to Table Script Generation and generate the Middleware tables by having the ‘Generate Middleware Tables’ checkbox checked)
3. If the above options does not help, then we really are in trouble, the issue could be with painting the ConnTrans GUI – we will have to take help of Regmon.exe and Filemon.exe, compare the results, of ConnTrans initialization with another system where ConnTrans works. By comparing the logs of Regmon.exe / FileMon.exe, we will come to know which dll does not get loaded and we can rectify it by registering it. This kind of situation will arise only when the Registry or the DLLs have been tampered.

Send and Receive Phases of ConnTrans:

The log file for this phase is "TransferService.log" which you could normally find in %temp% folder. The errors that you see in this log file will be a lot of help and will guide you to choose the option relevant for you.

The stupid question here is: Have you unchecked any of the SEND / RECEIVE phases?

If you see Red/Orange status bar for SEND ‘and’ RECEIVE:

1. You might need to check connection with CommStation and CRM server. For this, if you remember, we should be using ‘QmtCnfg.exe’.

There might be something wrong with the DBID and in such a case; you would be interested in Note 1253027.

If you see Red/Orange status bar for SEND alone:

1. You will have to check the top entry in the Mobile client outbound queue header MW_U_QOUT_50 and also in the data table MW_U_OUTDATA_50. Does the first header entry have all or any data in the data table? If not, something has gone wrong when saving the data in the outbound queue or the data has been tampered.

If you see Red/Orange status bar for RECEIVE alone:

This time we have to worry about the first set of entries in the server outbound queue for the site assigned to the Mobile client. It might be due to bigger size of the data. Normally, BDocs such as ATTACHMNT_WR, REPBOREPMA_WRITE will have a lot of entries that you might need to set an appropriate MAX_PACKAGE_SIZE. Note 874446 will be of help here.

The important binary used in this phase is MsgTransClient.dll and you might be interested to check Note 1028225 or Note 1071267whichever is applicable for you.

Import phase of ConnTrans:

The log file for this phase is "TL_TRACE.DAT". But you need to enable this log as follows:

1. Start ->

Regedit

1. Navigate to HKLM\SOFTWARE\SAP\MSA\MW\TL
2. Set TL_TRACE to 1
3. Set TL_TRACE_DIR to the desired directory where you want to see the log file.
4. If you want to have a look at the complete data that is received from the server as an XML, you could also set TL_SOAP = 3 to get an XML dump of the message received. Please make sure you use this only for tests or checks because this might end up filling your Hard Disk.

      Usually, the errors in Import phase will result in a ‘YELLOW’ status bar. If this is the case, it’s an application error – meaning, the data received from the server has not been properly put into application tables. These errors will always be reported back to the server and you will be able to locate them in Mobile Client Message Recovery transaction CMWQ. Suppose if these errors are related to constraints in the Mobile client IDES database (eg: Cannot insert NULL into x.y column), Note 1254280 will help you out.

      The trace in TL_TRACE.DAT will usually give you a good idea of what the error is. The usual errors are improper Metadata and improper Table scripts. ClientConsole.exe will come to the rescue in both the cases. All you need to do is to regenerate the Metadata or Table scripts for the failing BDoc properly. Please make sure you have the Unicode checkbox checked or unchecked according to the type of solution you have.

      What if the import does not start at all? This case is similar to the case where SEND ‘or’ RECEIVE does not work. You might need to check the MW_U_QIN_50 and MW_U_INDATA_50 tables, whether the header has its data mapped properly in the data table. You should also check the size of the data which is being imported, MSG_SIZE_C / MSG_SIZE_R will give you an idea. The size is in bytes and I have seen cases where data as heavy as 40 odd MB being imported successfully. If the data is huge in an extract, you might again need to consider reducing the size as per Note 874446.

Final phase of ConnTrans:

      After the data transfer is completed and ConnTrans closes its GUI, it tries to dispose off all the objects. It might fail to do so, if the destination configured in Mobile client is different from the destination which is configured at the CommStation. So QmtCnfg.exe is the tool for us here. Also make sure you have the latest HOTFIX notes applied – Note 1028225 or Note 1071267</strong> and Note 1036377.

General Comments about the SQL server installation and how it affects ConnTrans:

1. If you are going for SQL server 2005, never go for imaging an installation. But given no other choice, please make sure you fix the hostname issue you will face in the sysservers table of the SQL server master database if you image SQL server installations. What I mean here is that sysservers table will have the hostname of the original image and not the current laptop. There are numerous articles and Microsoft pages on the web on how to correct this scenario.
2. Please make sure you have the SQL server IDES database’s DB compatibility level to 80.
3. If you are running an extract and the laptop IDES DB’s size is going to be in the order of GB, then you might need to have a proper MAX memory limit for the SQL server installation. The Thumb rule is to set the MAX memory limit to ‘around’ 2/3 of the total Primary memory (RAM). For example, 800 MB would be an optimal value for a 2GB memory RAM. Why do you need this is because SQL server 2005, by design, keeps growing until it reaches the MAX memory limit. So if you have not set it properly, it will end up eating your RAM.

      So far we navigated through the world of ConnTrans and we do have some important answers with us. But the most important of them all is that the ConnTrans is designed for an online-offline scenario based on Microsoft Technologies and is inherently different from the technology and architecture of the ABAP based CRM system. There comes a need for a slightly different approach to the problems that you face simply because we will not be able to read the DLLs like we do the code in ABAP 🙂 and it is a reality that the ConnTrans application is on a laptop, carried on the field, used and incorrectly used by numerous users.