A.) Create new objects or checkout and modify existing resources
B.) When you create new objects (DCs or packages), the Name Service will be used (to check for unique names you have reserved in the SLD's Nameserver Configuration).
There are several ways to repair a broken DC, depending on the reason why it got broken:
Activate fixed version of broken DC
If the DC itself contains the error you should check out the affected files from DTR, fix the problem in
Developer Studio and then check-in and activate the new version. As a result of the activation the
DC will directly go from “broken” state to “OK” state.
Example: As announced before a deprecated interface was deleted by the provider. You change
your code and use a new interface that was specified as an alternative.
Activate/Import fixed version of used DC
If the DC was broken because of a problem in a used DC or build plug-in, the solution is to fix the
used DC. This can be done by editing and activating a new version of the used DC (if it is available
with its sources) or by importing a patched version of the used SC into CMS (if it is available as
archives). In both cases, the broken DC will become dirty first (scheduled for rebuild). After
successful rebuild, the DC will get the “OK” state.
Example: The owner of some DC has accidentally deleted a public part you are using. This DC was
built somewhere else and it was imported into your NWDI track as part of some used software
component. After you reported the problem, the owner of the DC has provided a fixed version. Your
NWDI administrator imports the software component archive with the fixed version into your track.
CBS automatically rebuilds all dependent components including your DC. Because the used public
part is now found, your DC can be built successfully and is no longer broken.
Administrative Rebuild
Sometimes a DC gets broken if a rebuild fails because of resource problems. In these cases, it is
enough to fix the resource problem and then trigger a rebuild. Therefore, it is not necessary to
change anything in the DCs themselves.
Example: There is not enough memory or the disk is full in the CBS server for some time. After the
server administrator has fixed the resource problem, NWDI administrators can use CBS Web UI to
rebuild individual DCs or whole SC compartments. After the successful rebuild, the DCs will go
directly from broken to OK state.
Initialize Compartment
In some rare cases internal caches of the CBS may be out of sync with the DTR.
Example: Think of a situation where you have no broken DCs or any pending requests but you have
a mismatch between the content of the files in the active workspace of DTR and the DC meta data or CBS
NWDI administrators can use the “initialize compartment” operation to repair this kind of inconsistency. tags: dirt dc's nwdi error, broken dc, non empty list of broken DCs, stopping export now,
This fix can repair dozens of broken DCs:
1.Use the CBS Web UI to find out which DCs are broken by itself.
open URL: http://<host>:<port>/devinf and navigate to the CBS.
a.Locate your build space and open the Compartments view.
b.Select one compartment. At the bottom of the page, you see a list of DCs. There you can filter for DCs that are broken by itself.
c.If there are DCs broken by itself find out why these DCs are broken and fix them.
d.Repeat for other compartments.
The version of your NWDI should be irrelevant to the version of NWDS you are using. However, NWDS should be the same as the target runtime system you are deploying solutions to. For Example if you are developing solutions for CE 7.2 SP07 then you should continue to use NWDS 7.2 SP07 .
NWDS version should match RTS(runtime system) version and not NWDI version.
Tags: What NWDS version should be used for NWDI 7.3 ? Netweaver developer studio NWDS version ,
Product: A piece of software that you run or sell to a customer. Products consist of software components (SCs). Software Component (SC): An installable piece of software. SCs contain development components (DC) and are (re-)used in products. SCs "know" their dependencies to other SCs. Development Component (DC): A piece of software on the granularity of an Eclipse-project containing all the development objects like java classes, interfaces, etc. What is new in DCs is that they define metadata as a add-on to a pure project, which define "DC-interfaces", the public parts, and use dependencies to other DCs - these are checked by the component-based build process. Track and Development Configuration: A track is a set of steps, "logical systems", and paths defined in the NWDI to create a product or SC version, defined by an administrator: From development to consolidation, assembly (which creates a new SC-archive), test, and production. One NWDI host many tracks.
A development component (DC) is an object in the SAP NetWeaver Developer Studio that represents a software unit that you develop. A DC is always assigned to a certain software component (SC). The DC contains the information for the software unit itself, for the relations between the different DCs and the parts they share – that is, the metadata of the development.
A development object is the part of the DC that you change or develop; it provides the DC with a certain part of its functionality. A development object can be a Java class, a Web Dynpro view, a table definition, a JSP page, and so on. Development objects are always stored as “sources” in the DTR repository. In a DC you can perform different types of development – for example, you can develop a Java project or a Web Services project.
