What is the Difference between SMT1 and SMT2?

[Former Member]

Recently i had to do a few steps for a system which is made a HADR system ?

As part of this steps i had to create entries in SMT2 Tcode.

But the process followed is similar to SMT1 steps.

So i want to know what is the difference between the 2 Tcodes?

[Former Member]

SMT1 - is the transaction run on the trusting system to create the trusted relationship between the trusting system and the trusted system.

SMT2 - is the transaction run on the trusted system where you can see the tab "systems that trust the current system". Double click on any of the entries in the tab to view the trusted - trusting connections.

[Former Member]

In the old 4.6 version of SAP, they used 2 separate transactions. SMT1 to create trusts and a separate SMT2 transaction to view the trusting systems. Since version 6.0, SAP has combined both SMT1 and SMT2 into the same transaction and just created 2 separate tab views. The first tab is the SMT1 transaction and the second tab is what we call SMT2: to view and maintain the trusting connections from the current system.

Trusted connections are only one way. A mutual trust requires you to execute SMT1 in both systems. Use SMT1 to “allow” a particular SAP system to make calls to the current SMT1 system.

With SMT2, the second tab, you see systems the “current” system wants to make calls to. SMT2 entries appear when an another system has executed SMT1 against the current system. Do not delete entries from SMT2. Rather, go to the target system and execute SMT1 and delete the entry from there and just refresh the display in SMT2 from the calling system.

Setting up a Trusted connection requires 2 steps; SMT1 for the technical connection and SMT2 to maintain the login access parameters of the trusting connection.

Step 1: from the system you want to make TRUSTED calls to - execute SMT1, and create/allow a specific SAP SID/Server to communicate and make Trusting RFC Calls. After executing SMT1 with the required RFC Destination a new entry will be created in the “allowed” system and view-able with SMT2 in that system.

Step 2: go to the system you just entered as the input of SMT1 in the first step and execute SMT2 that is, go to the second tab and double click and maintain the newly created Trusting RFC connection previously created by the system in the first step – we will call this Trusting Connection the target system in SMT2.

In the Admin tab of the target system , make modifiable the RFC parameters. Change Unicode to true and edit only the client number of the SAP system from the first step (ie. the corresponding SMT1 system client number – if there are multiple clients on the target server, enter the default login client number) - save and test authorizations and respond yes on exiting back to the main screen. Then perform a successful Status check.

Basically, since SMT1 created the SMT2 entry without a client number or Unicode set – you are forced to edit the SMT2 entry if you want the remote login to work and green lights on the status and authorization checks displaying properly. Only if SMT1 & SMT2 systems have identical client numbers will you get automatic green lights on the authorization/status checks. But, Unicode will not be set. Note: leave the language blank for the Chinese and other foreign language users since Unicode should be selected whenever possible.

If an authorization check fails, note the following:

T-RC = TECHNICAL Remote Connection - this is created by SMT1 from the Target System with the base RFC initially created with SM59.

L-RC = LOGIN Remote Connection - this is maintained in the Calling System with SMT2 but, errors are viewed in the SMT1 system with ST22.

Trusting system connections are a 2 step process where SMT1 creates the initial technical connection and SMT2 lets users test their authorizations against the target system they are trying to call. If the SMT2 target system is technically correct and the current user who is executing SMT2 gets authorization errors then, manually login into the target system and execute ST22 to view the current ABAP Dump created by all failed trusting login/authorization attempts in the Target System with various values for L-RC= ###. Apply the SAP secuirty instructions and re-test.    

If T-RC is not equal to zero then, the base RFC from the Target System must be fixed with SM59 and SMT1 re-executed.

There are some good tips at this link