cancel
Showing results for 
Search instead for 
Did you mean: 

Poll: DC Naming conventions: Acceptable length of DC name

Former Member
0 Kudos

Hi All,

My team is on a NW04S NWDI SP10 setup for WebDynpros.Recently we've been having many issues with DTR/CBS/CMS like, local remote name clashes, transport failing to Acceptance system, sometimes Webdynpro iViews dont show up in Acceptance system after a transport etc.

The NWDI Admin team is investigating the issues and found that the length of the DC name could be one of the reasons for these problems. And I'm doing my bit to help them reach a conclusion with regards to this specific reason.

The average length of DC names in our SCs is 12 (ranging from 8 - 16), even though SAP recommends the DC names should not be more than 8 characters long and the same is not enforced in the Studio.

Please treat this as a Poll as to how long your DC names have been on an average, and if you've come up with such or different issues which you could pin point to this reason.

Any suggestions/SAP Notes etc are also helpful.

I appreciate your help with points (for every post).

Many Thanks,

Rajit

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

The NWDI Admin team has concluded that this is not the real reason for the issue. They are still investigating. Thanks for all your help.

Former Member
0 Kudos

Hi,

Tips for Naming Components

When naming components, adhere to the following simple rules:

· The names of software components (SCs) and components (DCs) must be globally unique and static. The name of a component must be defined upon creation of that component and must not be changed afterwards. For more information on reserving globally unique component names, see Component Names.

· Dependencies between SCs are not declared for actual states or versions. Therefore, the names of software components should not contain explicit version or release identifiers.

Avoid names like example.org/component_1.0 and example.org/technology_6.30.

Instead, use simple names like example.org/component and example.org/technology.

· The assignment of DCs to SCs is not static and may change over time. Therefore, the name of a DC must not contain the name of the SC to which it will be assigned nor a version or release identifier of the SC.

Avoid names like example.org/sc/1.0/accounting. Instead, simply use example.org/accounting. Only if it serves to avoid ambiguity (for example, if another SC contains a component of the same name), can it be reasonable to use the SC name as a prefix, for example, example.org/sc/accounting.

· Dependencies between DCs are not declared for actual states or versions. Therefore, the names of components should not contain explicit version or release identifiers.

Avoid names like example.org/accounting/release_6.30. Instead, simply use example.org/accounting.

· The parent/child relationship between DCs is not static and may change over time. The name of a child DC can reflect the enclosure relationship, but this is not recommended, because such a name may lead to confusion when the relationship is changed. If it is probable or known that the structure of a component hierarchy will change (for example, a child component will be taken out of its parent’s enclosure), the name must not refer to the relationship.

The name example.org/customer_releations/accounting can become a problem, if example.org/customer_releations/accounting is now a child component of example.org/customer_relations, but is meant to be assigned to the new component example.org/financials later.

· Certain states of a DC may simultaneously be referenced from different workspaces (for example, from DEV and CONS). Therefore, the workspace identifier must not be part of the DC’s name.

Avoid names like example.org/accounting/DEV and example.org/accounting/CONS.

· Component names should not contain versioning or state information of any kind . This includes, for example, things like “specification” and “implementation” versions used on the J2EE platform.

· Component names must have a globally unique vendor identifier. This identifier is usually derived from an Internet domain that belongs to the vendor (for example, "sap.com").

If the Internet domain with the identifier example.org belongs to you, use it as a prefix to your component names, for example, example.org/accounting. This makes your component names unique among all vendors.

· Component names should not contain identifiers of developers, groups, or departments of a company. Responsibilities may change, but component names must not. Furthermore, do not use timestamps, dates, hosts, and so on..

Avoid names like example.org/department4711/accounting, example.org/john.dow/accounting or example.orgaccounting/09_11_2003_09.27pm.

· Component names should reflect the intended purpose and functionality of a component, and nothing else.

For further reading

http://help.sap.com/saphelp_nw04s/helpdata/en/82/236c42eed40e53e10000000a155106/frameset.htm

Component Names

Every component has a globally unique name. Component names are structured hierarchically and contain a unique vendor ID. You must define the name when you create the component; the name cannot be changed later.

The segments of a name are separated by slashes (“/”), and must start with the unique vendor identifier, followed by at least one more segment.

The syntax for component names is defined by the following rules:

component_name = vendor_id "/" name_segments

vendor_id = *( domainlabel "." ) toplabel

domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum

toplabel = alpha | alpha *( alphanum | "-" ) alphanum

name_segments = segment *( "/" segment )

segment = *pchar

pchar = alphanum | mark

mark = "-" | "_" | "." | "!" | "$"

alpha = "a" .. "z"

alphanum = alpha | "0" .. "9"

According to this pattern, allowed names are:

· sap.com/technology/logging, example.org/component_1.0

· example.org/customer-releations/accounting.

In this case, sap.com and example.org are vendor IDs derived from Internet domains.

The following names are not allowed:

· accounting(vendor ID is missing)

· example.org/componentaccounting („“ is not allowed)

· example.org/Component/ACCOUNTING (no uppercase)

The development infrastructure restricts the overall length of a component name to 40 characters. The requirements concerning the case, the character set to be used, and the maximum length of component names originate in the restrictions for paths and field names when the components are mapped to the file systems of certain operating systems.

Use only lowercase letters in component names.

Besides this technical name, a component should have a legible name intended for displaying and browsing. Define this display name when creating the component; it can contain any character from the Unicode character set.

Regards

Ayyapparaj

Message was edited by:

Ayyapparaj KV

Former Member
0 Kudos

Hi Ayyapparaj,

Thanks for the simple rules

Now, could you tell me the following in your setup:

1)Average length of your DCs

2)If you had DC name related issues earlier?

Regards,

Rajit

Former Member
0 Kudos

Hi,

Following are the lengthiest DC servicefinancialsquickcreate, inboundlogisticsrequestslist. Not yet faced any issues other than trying to remove them manually from windows OS. Due the 255char length issues.

Regards

Ayyapparaj