Need help with SAP terminology & team development

[Former Member]

Hello,

I'm having a difficult time comprehending the SAP terminology in the JDI.

I've been doing Java development for 6 years now so I feel like I have a good handle on Java terminology. I do NOT have any ABAP experience.

What would help me is some documentation that explains the meaning and purpose of the following:

- Product

- Domain

- Software Component

- Activity

- Development Component

I've been going thru the "Tutorial for Scenario 2+: Development with a Track" documentation

http://help.sap.com/saphelp_nw04/helpdata/en/21/82a9058fa8de46b1ba7522289345b2/frameset.htm

The tutorial uses all these terms but it doesn't really explain them in detail or in such a way that someone with a Java background can understand them.

Does anyone know of any documentation about team programming that is more detailed than the tutorial?

Any help would be appreciated.

Thanks!

David.

[Former Member · Accepted solution]

Hi David

Product is the one final relese let us say JDK 1.4.0 it is a combination of software components

Software component is group of Dovelopment components (DC)where as DC is group of Dovelopement objects( example simple javafile, webdynpro view, JSP,Servlet,HTML).

To Know more about TracK,domain,Activity ..go through the following link

http://help.sap.com/saphelp_erp2004/helpdata/en/56/d5a23fa34ffb47e10000000a114084/frameset.htm (infact its a part of Scenario 2+)

hope this helped you

Regards,

RK

[Former Member · Accepted solution]

RK,

Thanks for the link. I'll check that out.

David.

[Former Member · Accepted solution]

Hi David Some more Info

http://help.sap.com/saphelp_nw04/helpdata/en/49/d0ae143e94774a9423ca8c009dc76f/frameset.htm

Definitions

This section introduces the basic terms used in the document to explain the Design Time Repository (DTR). The terms used in the DTR are closely mapped to the DeltaV terminology.

.Activity: Used to represent a single logical change, where an activity tracks all the resources that were modified to effect that single logical change. When a resource is checked out, the user specifies which activity should be associated with a new version that will be created.

· Branch: All the versions created in the same workspace form a branch with increasing sequence numbers on the versions.

· Branch Relation: A version relation between the first version on a branch and its predecessor version.

· Merge Relation: A version relation that indicates that the contents of the source of the version relation were merged into the target version of the relation. There are different merge relations in DTR:

¡ Discard Merge: The source version of the version relation is discarded in favor of the target version of the merge relation (not yet supported in release 6.30)

¡ Edit Merge: The content of the target version of the merge relation is a result of merging its edit merge predecessor version with the immediate predecessor version in the same branch. This type of merge relation is created whenever several persons check out a file. The second person, who checks in his or her version, must execute the merge and creates an edit merge relation.

¡ Normal Merge: The content of the target version is obtained after merging the contents of the source version into it.

· Predecessor, successor, ancestor, descendant: When you check out a version-controlled resource and then check it in again, the originally checked-out version becomes the predecessor of the version created by the check-in. If a version is connected to another version across several predecessors, the first is an ancestor of the latter. The inverse of the predecessor and ancestor relations are the "successor" and "descendant" relations. Therefore, if X is a predecessor of Y, then Y is a successor of X, and if X is an ancestor of Y, then Y is a descendant of X.

· Resource: A file or a folder.

· Root Version: That version of the resource that is the ancestor of all the versions of the resource.

· Version: A resource that contains a copy of a particular state of a version-controlled resource. “Checking in” a checked-out resource creates a version.

· Version Control: A definition of a set of rules on how a development resource can be updated. A development resource under version control can either be in a checked-in or in a checked-out state.

· Version-Controlled Resource: When a resource is put under version control, it becomes a "version-controlled resource".

· Version Relation: A predecessor-successor relation between two versions of a version-controlled resource graphically represented by a line in the DTR Eclipse client.

· Workspace: A collection that contains multiple versioned resources but at most one version of each resource. Hence the workspace contains a certain state of a set of resources.

Workspaces behave like folders that contain pointers to the embedded versioned files and folders. In the DeltaV specification, these pointers are called “version-controlled resources”.

· Workspace Folder: A folder that contains workspaces. Workspace folders are not-versioned resources

Hope this helped you

Regards,

RK

[Former Member · Accepted solution]

RK,

Thank you very much for the great info and the link.

Although I'm still not totally comfortable with the terminology I'm going to mark this post as solved so you get the points.

I'll just open a new post if I have follow up questions.

Thanks again!!

David.