Skip to end of metadata
Go to start of metadata

Table of Contents

How to get the Development Configuration of a track via the CMS WebUI?

Have a look at this picture to see how to do it:

In case you would like to get the development configuration used by CBS for a particular buildspace, then proceed as follows:

CBS uses always the latest Development Configuration defined for a CBS Buildspace unlike the Developer Studio, which may have an outdated local copy.
You can get the Development Configuration used by CBS for a particular buildspace by invoking the following URL:

Back to top .

NWDI timezones – clarification
  • CMS UI always tells the timezone for displayed in the UI (usually being 'GMT', i.e. standard greenwich time' -without any 'summer time setting'. Example: in CMS webui you see: Processed at (GMT) 2012/07/23 05:49:30
    So this correponds to 6:49 MEZ or 7:59 MESZ (as being during 'summer time shift').
  • For external logs (e.g. engine traces or SDM logs etc.) CMS cannot influence the used time format, but usually it should also state details on the used time zone.
  • For TCS log files (import, assembly) the time display uses the server time zone, specifying in standard notation the time difference to GMT:
    So the mentioned example has
    ... Step Check-assembly at 2012-07-23 07:44:56.0075 +2:00
    so representing '7:44=GMT+2:00' or 5:44 GMT (and corresponds to MESZ).

Back to top .

Import of the build plugins is different on 640/70X and on higher releases

on 640:
In case of 640 (NW04) the procedure described in #891223 was the recommended way.
Therefore on 640 proceed this way:

  • Extract the file SAPBUILDT<SPSnum>.SCA (you can do this with 'jar -xvf SAPBUILDT<SPSnum>.SCA')
    There you'll find an SDA file cbsplugins.sda, and inside this file (same extract procedure) you can find the proper build plugins: , and
  • Copy the above mentioned build plugins into the CMS/inbox, i.e. the files you have extracted from SAPBUILDT<SPSnum>.SCA, then you can check them in on the 'check-in' tab of CMS.
  • Rebuild the track (you can find the build plugins under
    > Entry by Application Group > SAP NetWeaver > SAP NETWEAVER > SAP NETWEAVER 2004(S) > Entry by Component > Development Infrastructure ...)

Note: #891223 - How to Import Build Plugins to an NWDI track

on 700:
In case of 700 (NW04s) the checkin procedure is different, you can download the NW04s plugins directly and after copying to the cms inbox, they will be available.
See the same notes and tickets as above.

on >= 710:
Here you need to define again different SCAs, see the note for details to be able to decide which ones:
#1080927 - Creating CMS Tracks for Common Application Types
#1465468 - Required SCs for Specific Type of Development in 7.1 Track
#1463541 - Required SCs for Specific Type of Development in 7.2 Track
#1457908 - Required SCs for Specific Type of Development in 7.3 Track
#1572743 - Required SCs for Specific Type of Development in 7.31 Track

Back to top .

SCA Files are not visible on the check-in tab in transport studio of CMS

The behaviour (and the potential causes) is described in SAP note:
#1259604 - CMS check-in tab: Not all files from inbox are displayed

This implies that an SCA downloaded from e.g. a development system (i.e. not assembly step) will NOT be visible in the Inbox. Technically this can be checked by looking at the SAP_MANIFEST.MF of the SCA. The "pr_approvalstatus" must be "ASSEMBLED".

Actually there are two filters when you check in a file:
the first is the track configuration itself. The files in the CMS/inbox will be shown on the check in tab if they were really conigured on the track data tab in the landscape configurator. The second filter is the SAP_MANIFEST.MF file inside the SCA. If it has not the proper structure then it won't be possible to check in. This file guarantees that an SCA file is allowed for check in.

Back to top .

Choosing 3-digit or 4-digit CMS domain

Symptom: You proceed as per the note
#876701 - Name reservation of CMS domains in NWDI
to make a decision on using 3 or 4 digit CMS domain.
Document: Length of CMS domain

Back to top .

The way how deployment done between DEV/CONS and TEST/PROD is different

In essence importing to DEV/CONS system deployment is performed asynchronously on the configured runtime system.
When importing to TEST/PROD system deployment is done synchronously.

In case of DEV and CONS the software gets deployed only once it can be built. Since the system has to wait up the build results, the deployment request goes into a deploy queue (TCS Deployer) and once the build is succesful, the software gets deployed, i.e. this deployment is asynchronous.
Since in TEST/PROD the software is already assembled, there is no more need for any build, meaning the software can be deployed right after the import and therefore there is no need to queue the deployment request into the TCS's deploy queue (synchronous deployment).
Note: #793935 - Missing deployment during CMS import
Note: #793508 - Troubleshooting for the automatic deployment of the CMS

Back to top .

Which CRM SCs can be modified?,,,

are designed to be modified and extended in the NWDI. They contain the web files for the E-Commerce Applications, the IPC Web Applications and the Workforce Management Applications.

For E-Commerce for mySAP ERP:,

are designed to be modified.

If you plan to extend database tables:

you can modify this component as well.

The components,,,,

are designed not to be extended or modified in the NWDI. They are required for compiling and building the applications.

Back to top .

Our NWDI landscape does not fit the standard 4 systems
methodology advised by SAP

We currently don't have the hardware to set up development, consolidation, test and production systems. And frankly the amount of Java development work that we do does not warrant so many systems (we are only building our first WebDynpro application). But all the Development Infrastructure guidance in is for a 4 system Java Development Paradigm.

The four systems in NWDI (DEV, CONS, TEST, PROD) do not really mean that you need four physical instances or machines. It only indicates how you want to regulate the flow of changes in your environment. Think of these systems are just queues through which the changes flow. They all reside on the same CMS machine. Of course, if you need to have runtime-systems associated with these four systems, then you will need four other physical instances. But having a runtime system is completely optional.

Moreover, TEST and PROD are also optional. Only DEV and CONS are mandatory. There is no special reason for this - this is just the methodology widely followed by SAP customers and hence was ingrained into the product.

To simply get started, set up a track with only two systems - DEV and CONS. Do not specify any runtime systems. If necessary, you can use the same system that hosts CMS as the runtime system.

Back to top .

We would like to implement "QA approval"

We already have entries in the production queue which aren't yet imported. How can we apply QA approval to these already transported entries? If we configure QA approval now for the Production system, how does it affect the existing entries? Would the approval be applicable only to new entries and existing entries will not need any approval?

The "QA Approval" concept is present only in ABAP transports and not in NWDI. There is only one "approval" step in NWDI and that is after you assemble the SCA. That is, the assembled SCAs can either be approved or rejected. If it is needed to introduce one more check between assembly and production, then one can introduce a TEST system in the track (which will result in another tab in CMS). Then the SCAs must be 1) assembled 2) approved 3) imported into TEST system 4) imported into PROD system.

There is no way to bring entries back from the Production queue to the Test or Assembly queue. The easiest mechanism would be to re-assemble the SCAs (so that they get higher version IDs) and import these new SCAs into the Production or Test queue. Then these new SCAs will automatically outdate the older SCAs.

Back to top .

The import step has failed in CMS but the activation processing still continues in CBS in the background

Can you explain to me why even after the import step has failed in CMS, the activation processing still continues in CBS in the background? Even if the SAP NWDI is restarted, the processing in CBS continues. Is there any way to block it?

During the import process, CMS triggers the activation i.e., it creates an activation request in CBS. The request from CMS is put into a queue in CBS. CBS processes the requests in the queue asynchronously. CMS periodically polls this queue to see if its requests are processed. So even after a restart of the engine, CBS will pick up the old request and process it.

There is no way to "restart NWDI" - because there is no single NWDI application. NWDI consists of the three applications - DTR, CBS and CMS. One has to restart all the three to really restart NWDI.

Back to top .

What is "central server" in NWDI?

The 'central server' is part of DTR i.e., it is a component within DTR so that DTR can place locks (to prevent concurrent modifications) on the versioned artifacts in a central location, especially when DTR is running in a cluster mode.

The central server is started on the host where the first DTR instance in a cluster starts. For example, let us say you have a cluster with nodes NodeA and NodeB. If NodeA starts first, then DTR's central server will be started on NodeA along with the startup of DTR. It is basically an application listening on a particular server socket port for 'lock requests' from DTR and responding accordingly. Once NodeB starts, it detects that the central server is already running on NodeA and connects to it. This implies that there is exactly one instance of the DTR central server in the entire cluster. If NodeA crashes for whatever reason, then when the next client request comes to NodeB, then NodeB detects that NodeA is down and hence the central server is also down. It starts a new central server instance on NodeB which is an automatic recovery mechanism built into the central server in DTR.

The central server is an integrated part of DTR and only DTR uses this component.

Back to top .

I've imported the changes to CONS, but i want to assemble only certain part of it

After importing into the CONS it is not really possible.
Assembly means that the whole state of the software from the CONS/active workspace is taken for assemble.
Therefore you cannot filter out which changes should go into the assembly since they already have arrived in the cons system.
If you want to filter out changes that should not go into production then these changes should not be imported into consolidation before, since every change that is imported into cons will be part of the assembled software.
You can also delete DCs in dev and transport them to cons so that they will be deleted before assembly. (such a deletion should be able to activate even if there are predecessor activities to be activated)

Back to top .

Why do not check out from the active workspace

The error message "DTR workspace is not modifiable" by a checkout operation usually occurs, when files are checked out, to which a project belongs, which has been created for an active workspace i.e. dev/active or cons/active. In this workspace you musn't checkout any files, to this workspace only the CBS has write authorization in case of a succesful activation of an Activity.

You have synced the component from active workspace, this workspace is reserved for CBS hence Developer Studio tells you that you can't modify this workspace. Sync your DC you want to modify from the inactive workspace (e.g. in Development Configuration perspective sync sources for your DC from the view "Inactive DCs") then you should be able to checkout.

Back to top .

Unlock exclusive-checked-out file for editing

Customers ran into a problem when a file has been exclusively checked-out by a developer.
As the result, not possible for others to check-out and make a change to the file. Moreover it is not possible
for the person who exclusively checked-out the file to check-in or revert the open-activity using his/her own IDE installation.
In this case, using DTR web UI to search for that open activity and revert it is the simplest solution to "break" the file-lock.

Back to top .

Replicating a folder not working

Symptom: Attempting to replicate a folder residing in the root workspace, e.g. /ws/myfolder
Answer: This is not possible.

It is not allowed to replicate a FOLDER.
It is allowed to replicate only a WORKSPACE.

A workspace can of course have subfolders and files, but only workspaces can be replicated. (like in case of nwdi this is why we are always replicating /inactive or /active which are workspaces).

Further rules:
the root ws (this is the /ws) cannot have another workspace, only a
folder. This is why in normal nwdi development under the /ws you always have a trackname which is a folder, not a workspace.

Now consider the following structure that can be replicated:


This case the following command will work:

replicate -r -d c:\temp /ws/myfolderA/myworkspaceA XYZ /ws/myfolderB/myworkspaceB

Assuming you have in the target dtr (this can be the same dtr if you
use different names in folders and workspaces) the structure:

This case the result of the target DTR will be this structure:


Back to top .

No way to customize NWDI-related UME action

UME action is the smallest (atomic) unit, therefore this is not possible to customize it

Back to top .

How to update DB Statistics

You must be <SID>adm to perform this operation
On windows you can switch to <SID>adm this way:

runas /noprofile /user:<sid>adm cmd 
brconnect -u / -f stats -t all 

(brconnect is located usually under /usr/sap/<SID>/SYS/exe/run)

There is a background job in the DTR Server for updating the database statistics.
However this background job is only able to update the database statistics for SAP's MaxDB. For all other databases (so also for Oracle) the update of the database statistics has to be done manually.

Back to top .

Restrict deployment for developer users

You would like to avoid that developers are allowed to trigger deployment from NWDS, or via NWDI, CTS+, etc.

On 640/700 we have SDM, and there the situation is simple, if the developers are not aware of the SDM password, they cannot deploy.

The following answer is valid for releases >=710, i.e. where we got deploy controller:

You need to remove certain UME actions from the given user.
In AS Java either a user has permissions to deploy or it does not,
the tool used for the deployment is not considered. Those permissions are contained in actions

auth.all.all and

These actions are assigned to the Administrator role, but you are free to create a custom role containing only these actions and
assign this to users that should be permitted to deploy. However
from the point of view of the deploy service, it cannot be distinguished if the client is CTS+ or NWDS, both connect to the AS Java over p4/p4s to deploy.

Document: Security Actions Necessary to Perform Deploy Operations

Back to top .


You can see in the application log the following trace (example):

CBS Service version 7.30.0 has started on node 25434450 with following settings:
	JDK_HOME_PATHS = 'default=/usr/sap/ABC/J02/exe/sapjvm_6;'
	rootFolder = './temp/CBS'
	threadPoolSize = '3'
	BUILD_TOOL_VM_ARGS = '-Xmx1000m -XX:MaxPermSize=256m'
	notificationEnabled = 'false'
	nodeID = '25434450'
	notifyTCS = 'true'
	AdminTaskDelay = '5000'
	BUILDTOOL_JDK_HOME_ENGINE_JDK_HOME = '/usr/sap/ABC/J02/exe/sapjvm_6'
	cleanUpRequestFolders = 'true'
	tcsQueueCheckDelay = '10000'
	idleStart = 'false'
	useClassicSync = 'true'

This property is available only on 711 and 720 (on lower releases and as of 730 you won't see it). This is an internal property, you won't find it in CBS Service settings. The value of it is the JDK that is configured for the engine The purpose is that if BUILD_TOOL_JDK_HOME is not set in CBS Service settings, then BUILD_TOOL_JDK_HOME will use the value of BUILDTOOL_JDK_HOME_ENGINE_JDK_HOME.

Back to top .

How to increase the build timeout?

The reason for the failed build is a timeout - in the current implementation CBS is not allowed to spend more than one hour on a
single DC build. Usually, this is largely sufficient, and only for huge components does the build time come close to this limit.

> telnet <host> 5<port>08
> jump <node ID>
> setsp -p BUILD_TIMEOUT 120 tc.CBS.Service

Back to top .

  • No labels