Naming Conventions für PDC Objects

Dear all,
has anybody a document describing the naming conventions for PDC Object.
Example:
iv_xxxx for iViews
ro_xxxx for Roles
etc.
Thanks for help
Roman

Hi Roman,
check the SAP ASAP Roadmap for Enterprise Portal which can be found in [the SAP Service Marketplace|http://service.sap.com/roadmaps].
There you have several so called "accelerators" - one of those is a best practice document for naming conventions.
Look at Chapter 3.3.1.3
(I know because it is my slide set setup during an implementation project )
Hth,
Michael

Similar Messages

Change Existing objects naming conventions in a Query

Hi all,
I Need to change the Naming Conventions of the Query Objects of a Query at the Infoprovider level. Is there any Routine to change the naming conventions or do i need to do it Manually.

Hi gopinath,
mine is also a similar case, the problem with the option u gave me is that our implementation is in EDW environment and rework from the scratch is not an option for me. Is it possible to change the query objects naming convention at particular info-provider level, i have about 200 objects created with random naming convention and to be now changed according to a standard naming convention. I need to also consider how the changes effect other queries and reports as well.. So is there any possible way of Custom coding a routine or a program that can solve my purpose.. has any one gone through the same situation?
thanks,
kishore

SAP naming conventions: customer DDIC objects, ABAP programming

SAP Note 16466 Customer name range for SAP objects contains the SAP naming conventions for customer DDIC objects. Rule of thumb is that the names reserved for customer objects start with 'Y' or 'Z'. However, this note contains the naming convention for DDIC objects only.
ABAP Code Inspector (transaction SCI) contains the following naming convention for ABAP programming:
- Global types: T_
- Global constants: C_
- Global data: gv_
- Global field-symbols: FS_
- Global parameters: P_
- Global select-options: S_
- Global field-groups: FS_
- Local types: LT_
- Local constants: LC_
- Local data: v_
- Local field-symbols: LFS_
This is the only place I know for ABAP programming naming convention. Does SAP has somewhere else any additional naming convention guidelines for ABAP programming?
Thanks in advance for your help.
Regards,
Jarmo Tuominen

Naming convention guidelines for ABAP programming is available in here: [Manage Successful Customer Development|https://websmp206.sap-ag.de/~sapidb/011000358700004444532001E].
Naming Data Types and Objects
The names of data types and objects have the form: <Classifier>_<Data type>_<Descriptor>.
The names of data types and objects have up to 30 characters.
Exceptions: names of input parameters and select options have up to 8 characters, and <Data type> and _ are omitted.
First component: Classifier
T Data type
C Constant
G Global data object
L Local data object
FS Field symbol
P Input parameter
S Select option
P Formal parameter in form
FM Formal parameter in function
Second component: Data Type
<t> Elementary data type, optionally followed by length
C<n> Type C of length <n>
N<l> Type N of length <n>
X<l> Type X of length <n>
D    Type D
T    Type T
I    Type I
P<d> Type P with <d> decimals
F    Type F
WA Work area
IT Internal table
Third component: Descriptor
Use meaningful English names. Later, your code may be maintained or analyzed by a programmer or support consultant who is not familiar with another language.
Use only alphanumeric characters (A-Z and 0-9) and separate words with underscores (_). Hyphens are reserved for separating components in structured data types.
Examples:
G_I_COUNTER (global counter)
T_IT_BOOKING_LIST (type for list of bookings)
G_IT_BOOKINGS (global internal table of bookings)
PSMOKER (input parameter for smoker flag: note omission of data type and _ for brevity)
Edited by: Jarmo Tuominen on Feb 21, 2011 2:13 PM

Naming Conventions for EP

Hi all,
There some official document about Naming Conventions for EP?
Thanks.

Hi,
Portal objects naming convention.
The portal objects should utilize the following naming convention.
Folders: com.companyname.[functional area].[sub functional area].folders.[folder name]
Iview: com.companyname.[functional area].iviews.[Iview name]
Pages: com.companyname.[functional area].pages.[page name]
Transports: com.companyname.[functional area].transports.[Transport name]
Role: com.companyname.[functional area].[sub functional area].roles.[role name]
Worksets: com.companyname.[functional area].[sub functional area].worksets.[workset name]
Hope it helps.
Thanks
Mona

Question about Best Practices - Redwood Landscape/Object Naming Conventions

Having reviewed documentation and posts, I find that there is not that much information available in regards to best practices for the Redwood Scheduler in a SAP environment. We are running the free version.
1) The job scheduling for SAP reference book (SAP Press) recommends multiple Redwood installations and using export/import to move jobs and other redwood objects from say DEV->QAS->PROD. Presentations from the help.sap.com Web Site show the Redwood Scheduler linked to Solution Manager and handling job submissions for DEV-QAS-PROD. Point and Shoot (just be careful where you aim!) functionality is described as an advantage for the product. There is a SAP note (#895253) on making Redwood highly available. I am open to comments inputs and suggestions on this issue based on SAP client experiences.
2) Related to 1), I have not seen much documentation on Redwood object naming conventions. I am interested in hearing how SAP clients have dealt with Redwood object naming (i.e. applications, job streams, scripts, events, locks). To date, I have seen in a presentation where customer objects are named starting with Z_. I like to include the object type in the name (e.g. EVT - Event, CHN - Job Chain, SCR - Script, LCK - Lock) keeping in mind the character length limitation of 30 characters. I also have an associated issue with Event naming given that we have 4 environments (DEV, QA, Staging, PROD). Assuming that we are not about to have one installation per environment, then we need to include the environment in the event name. The downside here is that we lose transportability for the job stream. We need to modify the job chain to wait for a different event name when running in a different environment. Comments?

Hi Paul,
As suggested in book u2018job scheduling for SAP from SAPu2019 press it is better to have multiple instances of Cronacle version (at least 2 u2013 one for development & quality and other separate one for production. This will have no confusion).
Regarding transporting / replicating of the object definitions - it is really easy to import and export the objects like Events, Job Chain, Script, Locks etc. Also it is very easy and less time consuming to create a fresh in each system. Only complicated job chains creation can be time consuming.
In normal cases the testing for background jobs mostly happens only in SAP quality instance and then the final scheduling in production. So it is very much possible to just export the verified script / job chain form Cronacle quality instance and import the same in Cronacle production instance (use of Cronacle shell is really recommended for fast processing)
Regarding OSS note 895253 u2013 yes it is highly recommended to keep your central repository, processing server and licencing information on highly available clustered environment. This is very much required as Redwood Cronacle acts as central job scheduler in your SAP landscape (with OEM version).
As you have confirmed, you are using OEM and hence you have only one process server.
Regarding the conventions for names, it is recommended to create a centrally accessible naming convention document and then follow it. For example in my company we are using the naming convention for the jobs as Z_AAU_MM_ZCHGSTA2_AU01_LSV where A is for APAC region, AU is for Australia (country), MM is for Materials management and then ZCHGSTA2_AU01_LSV is the free text as provided by batch job requester.
For other Redwood Cronacle specific objects also you can derive naming conventions based on SAP instances like if you want all the related scripts / job chains to be stored in one application, its name can be APPL_<logical name of the instance>.
So in a nutshell, it is highly recommend
Also the integration of SAP solution manager with redwood is to receive monitoring and alerting data and to pass the Redwood Cronacle information to SAP SOL MAN to create single point of control. You can find information on the purpose of XAL and XMW interfaces in Cronacle help (F1).
Hope this answers your queries. Please write if you need some more information / help in this regard.
Best regards,
Vithal

What are the naming conventions we should follow while creating an object

hi
what are the naming conventions we should follow while creating an object in ABAP dictionary, i.e while creating zee table.

Hi,
Namespaces and Naming Conventions
SAP has reserved name ranges for customer objects and SAP objects. Use these customer name ranges to make sure that your objects are not overwritten by SAP objects during the import of corrections or an upgrade.
This documentation lists the customer name ranges for the different system objects.
Only use the customer name ranges. If you do not keep to the name ranges for customer objects you may lose your development objects.
SAP delivers a few system objects with names that fall within the customer name range. These objects already existed when the customer name range was extended from YY/ZZ to Y/Z. These objects are listed in table TDKZ.
Regards

BO Business Object Naming Convention

Hi experts,
we are about to implement SAP Business objects (previously using only using SAP BW). As part of the implementation we are creating a naming convention / standard for Webi and Universe. Is there anything published on SDN or the web regarding naming conventions / standards or is anyone willing to share some tips.
BR
Anders

Hi Anders,
In regards to naming your universe objects, please take a look at my blog post re Universe Best Practices (Link: [http://geek2live.net/posts/universe-design-best-practices/]).
I would always recommend naming universe objects (classes, dimensions, measures etc) in business terminology and being explicit in the definition. For instance, an object called 'Sales' could be interpreted many different ways. Is it Sales Revenue, Count of Sales Orders, Count of Sales Order Lines, Average Sales Amount, etc etc?
Your universes should also be named explicitly so users understand exactly what it contains. Another example - a Finance universe could contain many things - is it General Ledger Actuals, General Ledger Budgets, Fixed Assets, Accounts Payable etc..
The most important thing imho, is to define a standard that everyone who is designing universes uses, without exception. Otherwise the standards don't mean anything to the end users.
Good luck!
Josh

Enterprise Object (EO) Naming Conventions for Controls

Post Author: rnagahori
CA Forum: Nsite
When naming controls you should follow standard naming conventions. Good names
describe the control, such as prodName, effectiveDate, and dateRequired. Avoid
special characters like "-" ," /", "<" , or ">" when naming your controls.

Post Author: rnagahori
CA Forum: Nsite
Additional notes ... Avoid using the following list of Reserved Variable Names:Application Builder uses several reserved variable names. Please do not use
these as the names of controls, or as variables within Action Builder
routines.
Reserved Names
sum
min
max
avg
abstract
boolean
break
byte
case
catch
char
class
const
continue
default
do
double
else
extends
false
final
finally
float
for
function
goto
if
implements
import
in
instanceof
int
interface
long
native
new
null
package
private
protected
public
return
short
static
super
switch
synchronized
this
throw
throws
transient
true
try
var
void
validate
while
with
_allowSubmitOnError
_fields
_form
_locked
_name
_queue.errorFields
_queue.errors
_queue.validation
_parent
_pointers
_showAlerts
_skipValidation
_status
obj
addEvent
addField
addMethod
addValidator
changedFields
checkForErrors
disabled
dump
forceValidation
hasChanged
getFields
optional
onSubmit
onValidate
removeField
required
reset
setFields
submit
submitCheck
description

Looking for best practice on naming conventions

Does anyone out there have a best practice on naming conventions that they could share.
I'm starting to find the need to create objects and associated variables and actions.
I can see this getting very messy, very quickly and would love to learn if someone has come up with a good set of guidelines that are both easy to follow and make perfect sense. (I know....what a balance to ask for!)
Thanks
Alan

Hi Alan,
Welcome to Adobe Community.
There are couple of things that you can keep in mind while naming objects.
When creating custom text caption styles, be sure to follow the correct naming conventions. Each caption style has a unique name, and you must
use this name at the beginning of each associated bitmap filename. For example, if you create a text caption style named “Brightblue,” the five
bitmap images that constitute the new style should be named as follows:
Brightblue1.bmp, an image with no callouts
Brightblue2.bmp, an image with a callout to the right or upper-right
Brightblue3.bmp, an image with a callout to the left or upper-left
Brightblue4.bmp, an image with a callout to the lower right
Brightblue5.bmp, an image with a callout to the lower left
Flash button-naming conventions
Each SWF button contains three layers: a button, an icon, and an action layer.
The SWF filename consists of the following elements:
Acronym for playback control (“pbc”)
Playback element identifier (“Btn” for button, “Bar” for bar, and so on)
Name of the button (“play”).
Hope this helps!
Thanks!

Variable naming conventions

Hi all,
I come from a mostly JAVA background. Big emphasis in that arena on encapsulation and modularization of code to help facilitate ease of maintenance and reuse...in theory I sometimes struggle with variable naming conventions within my ABAP code because I'm not all together certain there are any. In C or C++ I might use a derivation of Hungarian notation to name varaibles...and in JAVA I might observe certain object oriented rules regarding varaible naming...I find myself using a combination of those two protocols in my ABAP code. Does anyone have any suggestions for how I might name global and lcoal variables within my code?
regards,
Mat

Hi,
Please check this links perhaps they may help.
http://help.sap.com/saphelp_nw04/helpdata/en/92/c2b084bc1d11d2958700a0c94260a5/content.htm
https://websmp101.sap-ag.de/~sapdownload/011000358700004455192006E/NameConventions.pdf
http://help.sap.com/saphelp_nw04/helpdata/en/2a/6b0b1f547a11d189600000e829fbbd/content.htm
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/011ccf90-0201-0010-92a7-b319adf89b73
http://web.mit.edu/sapr3/dev/newdevstand.html
Regards,
Ferry Lianto

Data Modeler - Naming Conventions

I was using Oracle Designer for several year.
This product could drive you crazy because sometimes, but the strength was in my opinion the datamodelling part.
It saved you a lot of time because you kept stuck to the logical model generated your relational model and had all scripts satisfying all naming conventions you needed.
In Data Modeler i really miss the naming conventions and can't understand some parts, sometimes somebody here can help me if i have overseen something or it is just not implemented.
Naming conventions as example:
We work with surrogate keys.
Two well known tables - Employees (abbreviation EMP), Departments (abbreviation DEP)
They have one relation 1:N one department has many employees
In Designer i would define the EMPLOYEE entity, would set the table-abbreviation, the attributes and the primary key.
The same with DEPARTMENT. I would design it WITHOUT any column for the foreign key constraint.
Then i would create a relation between this two tables.
Last step is to generate the relational model.
a) Designer automatically adds ID as surrogate key on every table (you could configure that, it was dependent on a domain)
b) it automatically adds the table abbreviation as prefix on every column (even here it's configurable)
c) it automatically adds the a foreign key column in the child table with the prefix of the master table (f.e. EMP_DEP_ID or DEP_ID if you prefer not to prefix every column... what i do)
It was really easy to get your scripts.
Things i don't understand in Data Modeler:
In a logical model you should design entities, attributes and relations and don't mess around with FK-columns.
Is there any support for surrogate keys? I don't wanna add an ID manually with every table.
In Data Modeler an additional COLUMN(!) is added with every Foreign key relation, i could live with that, but there is no way to tell
Data Modeler to prefix it automatically. The name can just be changed in the Relational View afterward.
P.S.
Surrogate Keys.... There are some pros and cons for/against this out there. I have seen a lot of Oracle Projects and in all except one i always had a surrogate key column. It really makes life
easier. In the one no-surrogate-key-project we began to add surrogate keys after a while...

COLUMN(!) is added with every Foreign key relation, i could live with that, but there is no way to tell
Data Modeler to prefix it automaticallyLook at "General options>Naming Standard>templates" - you can define template for FK columns/attributes and then apply them for whole relational/logical model using "Apply Naming .." functionality from pop-up menu in the browser. For Logical model (FK attributes) - you also need to clear related setting at "General options>Logical>Keep as the name of originating attribute".
Templates are also used when objects are created, thus when new FK is created, then templates are used to generate name for foreign key and FK columns. Well you have to define table and column abbreviation in order to get them used in generated names - Re: Data Modeler: Naming
There is no support for surrogate keys in current release.
Philip

User Tables Naming convention / Namespaces

Dear all,
Does anybody know where to get Informations about SBO NameSpace Conventions ?
I have 2 Questions for naming conventions
1) Creating a UserDefinedTable like this
   Table Name : Z_NameSpace_MyTableName
   Is it necessary that any FieldName of the
   table uses the NameSpace Prefix ?
   Like this: NameSpace_PosNo
2) Adding UDF to SBO Tables
   Is it necessary that UDF Fields uses the
   NameSpace Prefix ?
Thanks

Thomas,
The NameSpaces are only used while creating a UserDefined Table.
UserDefined Table :
The convention for the name is NameSpace_MyTableName (without the Z_). Its length can't exceed 19 characters.
When adding a user table, SAP Business One automatically adds the symbol @ as a prefix to the table name. For example: if you add a table named "ABC", the resulting table name will be "@ABC".
When referring to a user defined table you must use the name including the prefix @.
UserDefined Field :
you do not have to add the NameSpace in the name of the field. Its length can't exceed 8 characters.
When you create it using the UserFieldsMD object, the character "U_" will be added to its name, and created in the table.
To conclude, the NameSpace is only used for the table.
The DI API will add @ for the table, and U_ for the field.
You can see SAP note 647987 about NameSpace
Sebastien
Message was edited by: Sébastien Danober

Export-Import and Naming convention question

All,
Newbie here. Have a question related to the naming convention for SAP R/3 system and XI manual export/import process. We are currently in the development environment where our R/3 systems are named as D55CLNT400, D56CLNT300 etc (first 3 characters are the system id, and last 3 are the client number.) This is per the XI best practices convention.
The question i have is - if we name the technical system as above - and export the configuration objects from the Dev to Test environment - where the R/3 systems are named as T55CLNT400, T56CLNT300 (similar naming structure). Does it mean that we need to manually change almost all of the items in the Test environment on the configuration side (like business sytem name, interface determination, receiver determination etc)
Is this the correct way or are we missing something??? I would have preferred a way - where we needed to only update the communication channel parameters.
Thanks.
Message was edited by:
thezone

In the SLD, create three Business System Groups: DEV, QAS and PRD.
In each of these groups, you must have the relevant application servers (in your case, R/3s) and one integration server (XI).
Then, for each Business System in Group DEV, define a transport target in QAS group.
In your case, the transport landscape should be like this:
D55CLNT400 -> T55CLNT400
D56CLNT300 -> T56CLNT300
XI_DEV -> XI_QAS
Do the same for the QAS group (defining transport targets in PRD group). Observe that you need to have the same number of Business Systems in each group for this to work properly.
Now, when you transport your configuration objects from XI_DEV to XI_QAS, all the Business Systems in DEV landscape will be replaced for the equivalent ones in QAS landscape.
More info: http://help.sap.com/saphelp_nw2004s/helpdata/en/ef/a21e3e0987760be10000000a114084/frameset.htm
Regards,
Henrique.

Client Proxy Naming convention problem

Hi
I have created client proxy for the outbound interface for the scenario sap-xi-file...due to some naming convention problem i have to delete and create new all repository objects except message interfaces... so when i try to re-create the client proxy ..i am getting the "Naming conflicts" says the interface objects already exists.. can any one tell me how to remove my previous objects and create the new
guru

Hi,
check out this link on how to regenerate proxy objects:
(after the interface was changed)
http://help.sap.com/saphelp_nw04/helpdata/en/d4/255c3cf311070ae10000000a114084/frameset.htm
Regards,
michal

ADF BC naming convention suggestions

Ok, I havent found too many topics on this matter, but here is a list of naming conventions our team is debating over. I would also like to hear the rest of the community's thoughts.
Entity: Use underlying table's name and postfix with Eo. If the table is a W view, it should prefix with W.
eg. EmployeeEo, WEmployeeEo
View Object (Single entity based): Use the Entity's name postfix with Vo.
eg. EmployeeVo, WEmployeeVo
View Object (Multiple entity based): Use the primary entity's name followed by a "busniess task" name.
eg. DepartmentEmployeeSearchVo (employee search being the task).
View Object (Non-entity based): Use the primary query table name followed by a "busniess task" name.
eg.EmployeeCountVo
View Link & Association: Combine the master entity name and child entity name postfix with Vl/Ao.
eg. DepartmentEmployeeVl, DepartmentEmployeeAo
(The issue with this is our legacy tables are not that intuitivly named, so its hard to distinguish the master/child tables. I was thinking of splitting it with lets say 2, like Department2EmployeeVl)
Application Module: Apply a "busniess process" name and suffix with AppModule.
eg. AcmeAccountingAppModule.
If anyone has any suggestions or see any conventions left out please post them.
Thanks,
Z

Without discounting your object name conventions, don't forget the Java package they are placed in helps gives context for the object. This is what I tend to do:
com.acme.appmodules
com.acme.entities (all entities)
com.acme.entities.associations
com.acme.views (common VOs)
com.acme.views.links (common VO links)
com.acme.views.reference (common read only VO lookups)
com.acme.views.<business task> (to group logical business VOs together)
com.acme.views.<business task>.links
...the last 2 are repeated for each business task area (eg. HR, accounts, etc)
My ideas partially based on the SRDemo from the JDev team.
Hope this helps.
CM.

Naming Conventions für PDC Objects

Similar Messages

Maybe you are looking for