Naming Convention (Template) - Arc Constraints & Triggers

Hi
Using OSDDM 3.3.
There does not appear to be anywhere that the naming convention of Arc Constraints and their corresponding triggers can be specified.
This is touched on in discussion https://forums.oracle.com/message/9828101#9828101 I think.
If that thread is about this, I would like to add my vote to an enhancement request.
If not, then this is my request for such an enhancement request.
Thank you & Regards

This is not true, there is a set of schemas that Data Pump knows are really not user schemas and therefore are not exported. Most contain sys, but they don't have to.
If you created a schema called sysxyz, it would be exported.
Dean

Similar Messages

Naming convention in template css file

Is there a specific reason for having the theme "name" hardcoded in many css definitions ?
For example consider the css for the rows in a report:
In the css files for each theme it is defined in a different way:
Theme1: td.t1data
Theme2: td.t2data
Theme3: td.t3data
...Overriding these values and manipulating the styles using Javascript gets a bit cumbersome if it should work across themes.
Are there any naming conflicts or is it just for historic reasons that don't apply anymore in the 2.0 release?
In other words, would it be safe to use just td.data in new templates or will I run into problems doing this?
Thanks,
~Dietmar.

Hi Carl,
thanks for the clarification. I had figured that you had a good reason to do so.
It's a tradeoff, either approach has pros and cons.
Most likely we will stick with that type of naming convention, but we'll look into it again.I would like to throw in an idea. You can add multiple css classes to an html tag, e.g.
<td class="t12data data">The css for the class data would be empty.
This way we could have both, different class names for different themes, but also having the elements "tagged" the same way so that the javascript should work.
Haven't thought it out, it just came to my mind. You might consider it.
And yes using td.data should be just fineI guess I will go down that route.
I will create only a single theme and then use multiple css style sheets to modify the look and feel.
This way I can switch the theme on the fly by switching style sheets only.
Javascript modifications will work since the css class names are the same.
All customized region templates will only have to be created once (and not for all themes).
Thanks and a Happy New Year,
~Dietmar.

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

DataModeler v3.3.0 - Naming standards template for surrogate keys creation

I'm using DM 3.3.0.734 and in the logical model we now can define in the entity properties to "Create Surrogate Key".
When we use Engineer to relational model, for each entity is automatically created a new column using the naming template {entity}_ID as NUMERIC (without precision) and is defined as primary key.
My questions are:
Is possible to define a different naming standard for surrogate key creation?. We define id_{entiry}
Is possible to set the precision of NUMERIC surrogate key?
If we define entity's column as Primary UID, these columns are included in an unique constraint, but are using the naming standards for PK.
As consequence are created the following:
Unique constraint name: entity_PK
Primary key(surrogate)name: entity_PKv1
There is any way to define naming standards like "{entity}_UID" for unique constraints, or even, "{entity}_SK" for surrogate primary key name?
Can anyone help with some of these topics?
Regards,
Ariel.

Hi Ariel,
Naming standards template for surrogate keys creation I logged enhancement request for that.
How to change those bad names (going to change them one by one is not an option):
1) If those "transformed" unique keys are the only ones you have in relational model then simply can apply naming standards
2) You can write transformation script to do that for you
3) you can use new functionality - search, export to excel file, change the names there (using find/replace will be faster) and return changed data back to relational model
you can find description for that here:
https://apex.oracle.com/pls/apex/f?p=44785:24:13179871410726::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:6621,16
http://www.thatjeffsmith.com/archive/2012/11/sql-developer-data-modeler-v3-3-early-adopter-search/
http://www.thatjeffsmith.com/archive/2012/11/sql-developer-data-modeler-v3-3-early-adopter-collaborative-design-via-excel/
You should search for _PK, then filter result on Index and you can export result using report functionality (to XLS or XLSX output format). You can create template and include only table and name (of index) as properties to be included into report.
Regards,
Philip

SQL Developer - Data Modeler - Trigger for FK arc constraints

In the preferences there is an option "Data Modeler > DDL > Create Triggers for FK arc constraints". I think Oracle recomments to use constraints instead of triggers where it is possible. Can anyone from the Development team tell me why here is just the option to create triggers and not also the option to create table level constraints for FK arc constraints? If it is possible I'd like to have this option. My suggetion is to use the following check constraint construction for creation: nvl2(FK_IDx,1,0)+nvl2(FK_IDy,1,0)+...+nvl2(FK_IDz,1,0)=1 or with not only single FK columns: nvl2(FK_IDx1,1,0)+nvl2(FK_IDx2,1,0)+nvl2(FK_IDy,2,0)+...+nvl2(FK_IDz,2,0)=2. Please tell me if that would be possible (and maybe available in next Version) or why it is better to user triggers instead.
Thanks
/c

The Data Modeler forum is at:
SQL Developer Data Modeler

Naming conventions / Naming conventions for Trading Partner Management

Hello Experts,
Can any one share the Naming conventions / Naming conventions document for Trading Partner Management ?
Thanks
Saurabh

Hey Saurabh,
We usually go with the name and description for partners ,
Below blog might help
ISA and GS segments mapping - Value mapping v/s Predefined TPM UDFs - II
Suggestions-
Template - TM_Description
Function Profiles - FP_Description
Partners - TP_Description or PartnerName
Agreement - TPA_Description
Code List - CL_Description
Property key - lower case, description separated by dot (.) ( eg. seg.sep)
TPM Export file - Config_description .tpm
Regards,
Pooja

Purchase organization - naming convention

Hi,
Is there any best practice for the Purchase organization - naming convention in a global template project?
We have regional purchase organizations and country specific purchase organiozation in global template.
Regards,
AG

Thanks for your reply.
As the country specific purchasing organization will be linked to regional purchasing organization, should the naming convention of country specific purchasing organization, represents the first 2 digits of regional purchasing organization?

Private vs. protected, naming conventions etc.

I've been grappling with a couple of frustrations with Forte, and I'm
interested in feedback from others on this list regarding approaches
they may have adopted to address these.
One is that in the Forte workshops there is no way to view only the
public methods and attributes of a class (we're still using V2 here; I'm
assuming that V3 has not changed this). While referring to appropriate
technical documentation for a class is obviously important, I still find
myself opening up classes in the workshops to inspect the methods and
attributes available. (What I really want to see is an integrated class
browser. I sure hope Forte is working on something like this, or will
open up their development environment to support third-party extensions.
But that's an aside.)
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. Again, I'd be very interested in hearing how others have dealt
with this issue.
Thanks.
Michael Brennan
Programmer/Analyst
Amgen Inc.

I sent this once before, but the list seemed to be having trouble late last
week. If you get two copies of it... my apologies.
OK, I couldn't resist joining the fray...
At 10:56 AM 11/6/97 -0800, Michael Brennan wrote:
>
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.You might even designate a single character before the underscore to denote
that, just in case some environment (CORBA) doesn't like the "_". You could
make it something like "Q" or "Z" or something that wouldn't normally be
used alone at the start of a name.
>
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. I share your desire for protected methods, but I have to disagree about
protected attributes. Philosophically speaking, protected and public
attributes are EVIL!! (I say "philosophically speaking" because, in the
Forte environment, there are some valid reasons for using them based upon
the visibility constraints of the language. In other languages, C++ and
Java, for example, it's not even philosophically speaking - they're just
evil!!)
One of the principal reasons for adopting the object paradigm is to
tightly control the impact of change - to provide good boundaries of
encapsulation that change does not ripple beyond. If you think about it,
one of the measures of the success of a superclass is the number of
subclasses that it has (especially for a good dabstract interface). This
says you have very nicely captured the semantics of the application domain
in the interface of the superclass. So, let's imagine a superclass with
protected attributes that are used by each of its 100 subclasses (probably
more than you would have, but I'm illustrating my point - incidentally, I'm
not talking about a hierarchy 100 deep; I'm talking about 100 subclasses
that are all direct decendants of the superclass). Now you go and change
one of the attributes. You must go look at all 100 subclasses to determine
the impact of change. This is exactly the kind of thing the object paradigm
was designed to eliminate.
Protected methods, on the other hand, would be nice.
And At 12:06 PM 11/6/97 -0800, Mark S. Potts wrote:
>
Forte inherits in a strange way when attributes are private. A
superclass attribute that is made private is not accessible from any of
its subclasses - this means that many of what you would consider private
attributes in fact have to be public. Well, the definition of private means "not visible outside of the class
where it is defined". I find it useful to think of the level of visibility
the same as secrets. There are things that are not really secrets at all -
it's ok if anyone knows them ("My name is Stephen"). These are public.
Then, there are things that it's ok if my family knows, but I don't want
the world to know - familial secrets, if you will ("I belch at the dinner
table when I'm at home"). These are visible to descendant classes and we
call them protected. Finally, there are things we don't want anyone else
to know, no matter who they are ("I poisoned my mother-in-law"). These are
private. We don't want anyone outside of ourselves to know these things.
These are the classic definitions of public, protected and private (perhaps
classic only because C++ defined them that way and everyone else just
copied what it meant).
Private attributes are not meant to be inherited by their subclasses.
That's why they're private. And, yes, I would argue that that is completely
correct. What you want, if you want them to be visible to subclasses, is
"protected". Now, Forte doesn't support protected, but that's a different
arguement - perhaps even an enhancement request.
We also should not confuse what we need to do in a language/environment
with what good OO principles are. For example, good OO design principles
state that you do not have public or protected attributes. Period! You
access them via accessors and mutators defined on the appropriate class.
Now, in some environments, this will not give you the performance you need,
so you open things up a bit. But, you shouldn't convince yourself that
doing this is the ideal design, just that it was necessary for performance.
The real problem here is that the performance of accessor and mutator
functions is not fast enough. That's why we open it up. Not because it is
good design. The proper way to fix the problem is to make accessors and
mutators fast enough so that they can be used (C++, for example, does this
with "inline" - not that C++ is my favorite language, it's not. But they
have fixed this one area nicely.)
Some would argue that this is correct and that inheritance does break thepure rules
of encapsulation I don't think inheritance, properly handled (and Forte does properly
handle it) breaks any rules of encapsulation. I would argure that the way
they treat private attributes is quite correct.
- but these people dont build applications!Hmmm... let's see... started building OO applications in 1985 (and building
them ever since) in complex application domains like CAD/CAM/CAE, Air
Traffic Control, Graphics/Imaging, Telecommunications, e-commerce,
entertainment,... ...wrote (and teach) the Forte OO Analysis and Design
course.
I guess you're right. I don't build applications. I build robust,
maintainable, extendable applications. ( ;-) ...nudge, nudge!)
Stephen

Naming Conventions of Web Dynpro Wizard

Hello everyone,
is it possible to change the naming conventions of the coding generated by the web dynpro wizard?
According to our internal naming conventions object references (type ref to) are to be named LR_name, but the wizard is calling them LO_name.
Thanks in advance and best regards,
Alej

The templates/code fragments used by the wizard for generation are in the class CL_WDY_RG_FRAGMENT_TOOL, which in turn navigates down to local classes in the WDY_RG_CODE_TEMPALTES Function Group. For instanace the Context code fragements are in the local class LCL_COMPLEX_FRAGMENTS of this function group.
The fragements aren't in reusabe or customer maintable templates unfortuetely. They are built with CONCATENATE statements in these local classes. Newer developments (like the ABAP Code Completion in 7.02) use the ABAP Template Language (ATL) and have a tool to maintain these templates directly. However for the WD Code Wizard, you would have to use the Enhancement Framework or Modification Assistant to adjust the concatenate statements in the local classes.

Naming Conventions for Workflow

Hello,
does anybody have a document for Naming Conventions for Workflow.
I found nothing the last hour.
Thanks in advance for any help ...
Stefanie

Hi,
I am sending you naming convention which we followed in our project.
Workflow Template & Standard Task:
SAP/R3 Limitations:
Workflow Template & Standard Task names are limited to 12 bytes.
Standard:
Bytes 1-3 of the Workflow Template & Standard Task (see following table) are intended to give an overview of general information regarding the Workflow Template & Standard Task.
Characters 4-12 of the name should be chosen to impart some idea of the Workflow Template & Standard Tasku2019s use and/or contents. (The portion of the Workflow Template & Standard Task name that forms the unique identifier may, or may not, contain underscores characters to enhance Workflow Template & Standard Task name readability.)
Position Description Sample Values Sample Meanings
1 Table system life Z/Y Permanent/Temporary
2 Application Type * See Application Designators (Appendix B)
3 OPCO/Region * See OpCo Initial Chart (Appendix A)
4-12 Unique identifier text Unique identifier; may include underscores
Example: ZS7_IDEL9 (I:-Inbound, DEL: - OILDEL 9:- Original)
Business Object:
SAP/R3 Limitations:
Business Object names are limited to 10 bytes.
Standard:
Bytes 1-3 of the Business Object (see following table) are intended to give an overview of general information regarding the Business Object.
Characters 4-12 of the name should be chosen to impart some idea of the Business Objectu2019s use and/or contents. (The portion of the Business Object name that forms the unique identifier may, or may not, contain underscores characters to enhance Business Object name readability.)
Position Description Sample Values Sample Meanings
1 Table system life Z
Y Permanent
Temporary
2 Application Type * See Application Designators (Appendix B)
3 OPCO/Region * See OpCo Initial Chart (Appendix A)
4-12 Unique identifier text Unique identifier; may include underscores
Example: ZS7_OILDEL (Business Object for OILDEL Message Type)
Methods
Method names should begin with a verb:
Examples: GET_STATUS, CREATE_ORDER, DETERMINE_PRICE
For Parameters:
IMPORTING parameters IM_<parameter name>
EXPORTING parameters EX_<parameter name>
CHANGING parameters CH_<parameter name>
RESULT RE_<result>
Events
Event names should have the form
<noun>_<participle>:
Examples: BUTTON_PUSHED, COMPANY_CODE_CHANGED, BUSINESS_PARTNER_PRINTED
Note: There is no specific naming convention for Container Variables in workflow & for Key Fields & Attributes in Business Object. These variables name should be chosen to impart some idea of the variablesu2019 use and/or contents.
Appendix A
ABAP Programming Standards: OpCo/Region Initial Chart
Old # Company Name Proposed # Accounting Location
98 Common A San Ramon
95 FSC B San Ramon
80 Chevron Chemical Company C San Ramon
89 Chevron USA-Downstream & General D Walnut Creek
75 Chevron Real Estate Management E San Francisco
76 Chevron Information Technology Company F San Ramon
77 Gulf Oil Great Britain G London
85 Corporation (Acct. by Corp.) H San Francisco
83 Chevron International Oil company J San Ramon
87 Chevron U. K. Limited K England
86 Corporation (Acct. - Local Office) L Various
96 P&M Coal & Mining Company M Denver
94 Corporation (New York) N New York
90 Chevron Pipeline Company P San Ramon
79 Chevron Canada Resources, Ltd. R Calgary
92 Chevron Shipping Company S San Francisco
81 Chevron Petroleum & Tech Co. T Houston
91 Chevron USA Upstream U Concord
78 Chevron Canada, Ltd. V Vancouver
93 CUSA Warren Petroleum W Tulsa
84 Chevron Overseas Petroleum, Inc. X San Ramon
88 Chevron Research & Tech. Company Y Richmond
- Corp. GLX Common validations Z San Ramon
- PCA 3 San Ramon
- Tax 4 San Ramon
- Audit 5 San Ramon
- Asia-Pacific 6 Global
- Africa 7 Global
- Latin America 8 Global
Appendix B
ABAP Programming Standards: Application Designators
A Assets Accounting
C PPC
D DASS (control station)
E RIVA/IS-Oil
F Financial Accounting (incl. Joint Venture)
G General Ledger
H Human Resources Planning
I Plant Maintenance
J Publishing
K Cost Accounting
L Inventory Management
M Materials Management
N Hospital
O unassigned
P Human Resources
Q QSS (Quality assurance)
R PRA (Prod & Revenue Acctg)
S Basis
T Projects
U Enterprise Data Model
V Sales
W MMS (Merchandise mgt. System)
X unassigned
Y Customer head office
Z Customer branch
<inappropriate content removed by moderator>
Thanks
Yogesh Sharma
Edited by: Mike Pokraka on Jul 2, 2008 10:34 AM

Draft forms in Queue do not have naming convention

When a form is saved as a draft, there isn't any naming conventions such as the Task Display Name, Process #, or Task #, etc. Is it possible to include some type of naming distinction in the draft forms?
We have multiple forms in Draft and when I need to open a specific form, I must open each form to find the specific form.

Search Templates should help here : LiveCycle ES2.5 * LiveCycle ES2.5 Administration Help
It shows the tasks saved in Draft as well :
Thanks,
Wasil

VC models...BeX naming conventions

Hello,
I have a problem in VC...with naming conventions.
The base Bex queries were not followed Naming Conventions and the VC models were completely designed based on the queries.
Now the management had decided to move the content only with naming conventions...from Bex we can do the query as Save As in a simple way. What about VC? Can we do it similar...i dont think so. Can someone help me with the best solution how to solve this issue.
what i did: I took the copy of VC model and added new datasource (Bex new query followed naming convention). Then i try to drag the input and output links to the new datasource i cant able to do that, is there a best way? my other question is if i change the links from old datasource to new datasource then all the fields and values for the rest of the model are blanked (not copied from the previous model). How to best solve this issue? Please advice...and consider this as high priority.
Note: If there is no solution to my question, how could SAP develop the tools with out thinking these constraints during the Product development. I feel like strange...please respond.
Thanks,
Pandu
Edited by: pandu on Jun 15, 2010 12:29 PM

Hi
I have a doubt regarding your requirement.
If you are creating new Bi queries, (with Save As) so what your are going to do with existing queries? If not, you can continue with same VC model, you just need to change model name as per convention.
Also for the second point you mentioned, VC is just for arranging the layout of the dashboard & the layout will remain same even if you delete exisitng queries & add new queries. Also the Data service (BI Query in this case) is a foundation of VC model & all other things like Input/ Output Form/Table are with reference to data service. So if you are deleting data service obviously all values will get reset. There are few constraints in VC but i dont think this is a constraint.
If possible, follow the naming convention in discripption of query for earlier queries which will not lead to duplication of efforts for earlier queries & Vc models. & You can start following naming convention for new queries.
Regards
Sandeep

Standard Naming Conventions in XI

Hello,
Pls send pdfs/links for Naming Conventions in XI
Regards

Hi Henry,
These r the naming conventions to be followed in XI :
1) For Software Component, the naming convention should be :
 SAP_<SID>
where <SID> is the system ID if the applicable system
2) For Software Component Version, the naming convention should be :
 X.X
which shows the applicable version as of this date. Eg. SAP_ECC is at version 5.0
3) For Namespace the naming convention should be :
http://ERPGenie.COM/xi/<SCENARIO>/<SID>
where scenario refers to the interface being developed for and <SID> is the component where that object has relevance.
Eg. http://ERPGenie.COM/xi/OrderOutput/ECC will contain all the objects relevant to the Order Output scenario in the ECC system.
4) In Interface Objects ,
a) Message Interface should have the following naming convention :
MI_<meaningful name>_<IN/OUT/AB>
where:
IN = Inbound
OUT = Outbound
AB = Abstract (For BPM)
Remember to evaluate the IN and OUT based on the point of view from the source system to the target system. Eg. If we send an XML message from xEXTERNAL to an IDoc in ECC, then the XML Message is an OUT and the ECC is an IN interface.
b) Message Type should have the following naming convention :
MT_<meaningful name>
c) Fault Message Type should have the following naming convention :
FMT_<meaningful name>
d) Data Type should have the following naming convention :
DT_<meaningful name>
e) Data Type Enhancements should have the following naming convention :
DTE_<meaningful name>
f) Context Object should have the following naming convention :
CO_<meaningful name>
g) External Definition should have the following naming convention :
ED_<meaningful name>
5) In Mapping Objects,
a) Message Mapping should have the following naming convention :
MM_<meaningful name>_<source type>_<target type>
Eg. MM_ORDERSCENARIO_ORDERS05_OrderXML
b) Interface Mapping should have the following naming convention :
IM__<meaningful name>_<source type>_<target type>
Eg. IM_ORDERSCENARIO_ORDERS05_OrderXML
c) Mapping Templates should have the following naming convention :
MT__<meaningful name>_<source type>_<target type>
d) Imported Archives should have the following naming convention :
IA_<meaningful name>
6) In Services
a) Business Systems should have the following naming convention :
SAP<SID>
Where <SID> is the relevant system ID number
E.g.. SAPECC, SAPCRM, SAP46C
b) Business Services should have the following naming convention :
SRV_<XXXXXX>
Where XXXXXX is up to 6 characters to describe the type of service.
E.g. SRV_MAIL, SRV_FTP, SRV_SEEBRG
7) In Adapter Objects,
a) Adapter Meta Data should have the following naming convention :
AM_<meaningful name>
b) Communication Channel should have the following naming convention :
CC_<meaningful name>_<sender/receiver>
 E.g. CC_MAIL_SENDER
8) In Integration Objects,
a) Integration Process should have the following naming convention :
IP_<meaningful name> (Keep to 10 or less characters ALL CAPS)
 Store these in namespace http://ERPGenie.COM/xi/<SCENARIO>
b) Actions should have the following naming convention :
<meaningful name>
Use Send_ or Receive_ to denote the sending or receiving of messages
Store these in namespace http://ERPGenie.COM/xi/<SCENARIO>/<SID> where <SID> is system where the action is to be performed.
c) Integration Scenarios should have the following naming convention :
IS_<meaningful name> (Keep to 10 or less characters ALL CAPS)
The following web-sites may be helpful for complete naming standards in XI :
http://tsr.strain.at/space/SAP+XI(This web-site gives all detailed information about XI)
http://www.erpgenie.com/sap/netweaver/xi/namingconventions.htm
*********Please reward points if u find this useful.
cheers,
gyanaraj

Naming Convention and way to locate Table Names in B.I

Hello All,
I like to know information about
How to find a table
Naming convention of table
Important Tables
I will be thankful ,if anyone provide this information..

Hi Path,
I will provide information what i had got through various sources...
1) Identifying Table
The best way to find out from which tables the data source is getting updated is to search in help.sap.com by using the selection criteria "datasource and the name of the data source".
This displays a table which gives the name of the fields and the table names
2) Naming Convention
1./bic/f (cube name) is the fact table of a content cube
2./bic/D (cube name) P is the package dimension of a content cube
3./bic/D(cube name) U is the unit dimension of a content cube
4./bic/D(cube name) T is the time dimension of a content cube
5./bic/D(cube name) I is the user defined dimension of a content cube
6./bic/m (object name) master data of object
7./bic/t (object name) text data of object
8./bic/H (object name) hierarchy data of object
9./BIC/I* SID Structure of Hierarchies
10./BIC/K* Conversion of Hierarchy Nodes - SID
11./BIC/P* Master Data (Time-Ind.): Characteri
12./BIC/Q* Master Data (Time-Ind.): Characteri
13./BIC/S* Master Data IDs: InfoObject
14./BIC/T* Texts: Char.
15./BIC/X* Attribute SID Table: InfoObject
16./BIC/Y* Attribute SID Table (Time-Dep.):
17./BIC/B* Transfer structure PSA/Changelog
18./BIC/A* ODS Active records
19./BIC/F* Info cube F-Fact table
20.BIC/E* Info cube E-Fact table (compressed records)
21./BIC/D* info cube dimension tables
3) Important tables
I has collected some important tables that may help you..
authorization:
RSSTOBJDIR (Management Table for Authorization Objects): Link between specific authorization object and Info source (table used by transaction RSSM)
InfoPackage
RSLDPIO Links datasource to infopackages
RSLDPIOT InfoPackage Text Description
RSLDPRULE ABAP source code for InfoPackages
RSLDPSEL Hardcoded selections in InfoPackages
ProcessChain
RSEVENTCHAIN Event Chain Processing Event Table
RSEVENTHEAD Header for the event chain
RSEVENTHEADT Header for the event chain
RSPCCHAIN Process chain
RSPCCHAINATTR Attributes for a Process Chain
Queries
RSZELTDIR Directory of the reporting component elements
RSZELTTXT Texts of reporting component elements
RSZELTXREF Directory of query element references
RSRREPDIR Directory of all reports (Query GENUNIID)
RSZCOMPDIR Directory of reporting components
Workbooks
RSRWBINDEX?
List of binary large objects (Excel workbooks)
RSRWBINDEXT?
Titles of binary objects (Excel workbooks)
RSRWBSTORE?
Storage for binary large objects (Excel workbooks)
RSRWBTEMPLATE?
Assignment of Excel workbooks as personal templates
RSRWORKBOOK?
Where-used list for reports in workbooks

NWDI naming conventions

Hi,
does anybody know about documentation with proposals of naming conventions for
- products
- software units
- Software components
- Tracks
and so on?
Would be great to get a link.
Thanks in advance
Norbert

Hi Norbert,
there are not much conventions for naming of that entities. The most obviuos and well known ones are given/referenced below.
the very first and the most important is namespace (aka vendor aka prefix - depending on the context)
in order to avoid any collisions it is always strongly recommended to use a reverse internet domain reserved by your company as a vendor or prefix for all named entities.
in that way for SAP the vendor/prefix should be "com.sap", for MSFT - "com.microsoft", for W3C - "org.w3" etc.
Further constraints you might find in SLD:
- help
- namereservation dialogs contain additional information
- you might also have a look at <a href="http://help.sap.com/saphelp_nwce10/helpdata/en/45/5a1babec592a4de10000000a11466f/frameset.htm">NW CE 7.1 SP3 help</a> (the rules are about the same for other releases)
A few more hints
- it is not recommended to repeat the vendor/prefix in the main part of the name,
instead of vendor "org.demo.my", name "my.org.demo.abc"
recommended: vendor "org.demo.my", name "abc"
- there is no need to include entity type in the name, e.g.
instead of name "my.demo.org.DC.my.application"
recommended: vendor "my.demo.org", name "my.application"
- if necessary (only you may now if it is the case), define a prefix per product and use it consistently in all entities those belong to the product. That would be particularly hepful if you plan to develop more than one product
- pay attention to the case(!)
If the information is too generic - you might give few examples those would help you to get better feeling.

Naming Convention (Template) - Arc Constraints & Triggers

Similar Messages

Maybe you are looking for