Naming conventions, corporate governance standards, etc.

We're beginning the process of setting up the Oracle portal in our company to support over 300 communities of practice as well as several other applications. Getting our corporate governance, naming standards, taxonomy usage guidelines, etc. outlined up front (and right!) will be critical to the success of the program. There seem to be infinite options within the portal product.
Have you developed standards, governance, guidelines, etc. for usage within your portal environment? What lessons did you learn along the way? What advice and recommendations would you give someone starting out to do the same?
Thanks.

Hi,
Did You get or made your own portelt and portlet parameter conventions?
If yes could you share it with me please?
At least the viewpoints, cornerstons of it?
Thanks.

Similar Messages

OWB Naming Conventions and Development Standards

Hi all,
I am developing a project in OWB. Could any one give me 'OWB Naming Conventions and Development Standards' document.

Hi,
You want to post this to the OWB forum:
Warehouse Builder
Thanks, Mark

Naming Conventions and Development Standards'

Hi all,
I am developing a project in OWB. Could any one give me 'OWB Naming Conventions and Development Standards' document.
Thanks

Hi,
You want to post this to the OWB forum:
Warehouse Builder
Thanks, Mark

Question about CEP Naming Conventions and or Standards

Hello,
CEP is new to the organization that I am working with. I have been asked to draft a few standards around CEP to help promote standardization and proper reuse of CEP artifacts. Can anyone share with me examples of CEP artifacts with a naming convention or their experiences with naming conventions around CEP in general. This is a living standards document for us. We plan on using CEP heavily going forward. Your experiences will help us start off on the right foot.
Thanks in advance,
JJE
Spelling Edited by: JJ.Everett on Sep 7, 2010 11:16 PM

Hi,
Oracle CEP supports reuse of components in several ways. For example, you can design your application as a set of modules that can be deployed independently (different teams can develop each module). Modules can register services, such as an event source or event consumer, and these services can be used by other modules. So, it's possible to plug modules developed by different teams of developers together and reuse them in different applications or environments. A component instance registers itself as a service when its advertise attribute is set to true in the Spring application context that defines a module.
A component implementation can also register a factory as a service that allows instances of the component to be created by other modules. Section 13.1.5 in the CEP Developer Guide describes this. http://download.oracle.com/docs/cd/E14571_01/doc.1111/e14301/adapters.htm#CIHBHEDA
Hope that helps.
Regards,
Seth

Naming Conventions and Other Standards

Does anyone have a set of standards and conventions you use when publishing Captivate Flash files to the Web? I'm looking for a laundry list of settings to check while publishing? Thanks

Hi,
You want to post this to the OWB forum:
Warehouse Builder
Thanks, Mark

BPEL naming convention

Hi Folks,
I am looking for Oracle BPEL naming convention and coding standards. Tried to search at oracle site as well as on internet but didnt find anything.
Could you please help me with some document/link for naming convention and coding standards.
Thanks
Amit

Hi Amit,
Was able to pull this info from my inrenal repo..thanks to the people who made this :)
Naming Convention: ActivityDescription_suffix_
* ActivityDescription should use camel casing.
copyLeadInfo_asgn
Process Activities
     Services
     ESB Services
Item      suffix      Item      suffix      Item      suffix
Assign      asgn      AQ Adapter      aq      Routing Service      rs
Compensate      cmpnst      Database Adapter      db      SOAP Service      ss
Decide      dcd      Decision Service      dsvc      Custom Adapter      ca
Email      eml      EJB Web Service      ews
Empty      ept      File Adapter      fl
Fax      fax      Java Web Service      jws
Flow      flw      JMS Adapter      jms
FlowN      flwn      MQ Adapter      mq
Human Task      hmntsk      Oracle Applications      oraapps
Invoke      invk      Partner Link      pl
Java Embedding      jvEmbd      FTP Adapter      ftp
Pager      pgr
Pick      pck
Receive      rcv
Reply      rply
Scope      scp
Sequence      sqn
SMS      sms
Switch      swth
Terminate      trmnt
Throw      thrw
Transform      xfrm
Voice      vc
Wait      wt
While      whl
Sensor Actions      snrctn
Sensor Activity      snsrcvt
Sensor Variable      snsrvrbl
Fault Sensor      snsrflt
Also, you can refer : http://my.oracle.com/portal/page/myo/emea/Communities/Technology/EMEA_SOA_Integration/KA
Hope it helps!
Regards
Anirudh Pucha

SAP Documentation for NWDI Naming convention

Hi,
I need SAP documentation for NWDI Naming convention, Produt, unit, SC etc..
Thanks

Hi,
This is the link for SAP NWDI
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/e0b2b146-5776-2910-4a8f-9b3190eab060&overridelayout=true
Regards,
Niraj

Oracle BPEL standard, best practice and naming convention

Hi, folks,
Is there any standard or best practice associated with Oracle BPEL, regarding development, performace, what to avoid, etc? And is there any naming convention for the process, variable partner link name, etc? Similar to naming convention in writing Java code?
Thanks
John

Hi,
Here is the best practice guide:
http://download.oracle.com/technology/tech/soa/soa_best_practices_1013x_drop3.pdf
Thanks & Regards,
Dharmendra
http://soa-howto.blogspot.com

Adobe Interactive Forms - Standards & Naming Conventions

Does anyone know where I can locate any documentation pertaining to recommended standards and naming conventions for interactive forms within the SAP NetWeaver '04 platform?

Hi David,
I suggest you start here: https://www.sdn.sap.com/sdn/developerareas/was.sdn?page=AdobeForms.htm. This is where we have collected background information, demos, eLearning materials, and links to the standard documentation for the integrated forms solution. We work together with Adobe on the content of this site.
In due course, we will provide more tips & tricks and best practices.

How to create new check for SELECT* , Naming conventions etc..

Hi all,
   I would like have a solution for the below checks are possible or not in ABAP - CODE INSPECTOR. If possible can you please give me the solution..
a). Performance checks i.e, SELECT* , LOOP without field strings, FOR ALL ENTRIES IN SELECT STATEMENT.
b). Custom naming conventions.
c). to check if further modularization can be done in the program,
d). also the coding standards.
PLEASE help me , i am struck with it for long time in getting the solution...

> a). Performance checks i.e, SELECT* , LOOP without field strings, FOR ALL ENTRIES IN SELECT STATEMENT.
> b). Custom naming conventions.
> c). to check if further modularization can be done in the program,
> d). also the coding standards.
the code inspector allows the creation of new checks, you should consult the documentation how to do it.
The main problem of the code inspector are hits, which are actually no problem. And I think this is a problem with your checks:
+ SELECT* this is no performance problem, only in cases when the table is really wide then a field list makes sense, i.e your check
   will find a lot of false hits
+ LOOP without field strings ... you mean fs =field symbols, same as with SELECT *
+ FOR ALL ENTRIES IN SELECT STATEMENT   ???? FOR ALL ENTRIES is fine
+ Custom naming conventions ... hmmm be more precise, I think it can be hard
+ to check if further modularization can be done in the program,
    before you want to program can you please explain how you check manually .... I would be interested
+ also the coding standards.   .... what is that?

BPC Standard Naming Convention

Hi Gurus,
Could you please share BPC naming conventions standards?
I am looking for prefix for objects such as:
Environment
Model
Dimension
Team
Task Profile
Data Access Profile
Member Formulas
Logic Script
Business Rule
Controls
Input Screen
Report
Data Manager Package
Data Manager Package Link
Transformation File
Conversion File
Process Chain
Thanks.

As far as I know there are no naming conventions other than no special characters or spaces. NW is case sensitive, so you need to be careful there. In terms of prefixes, I'm not sure what you mean. Some of the technical objects in NW are in the CPMB namespace but you are not adding that namespace to anything
Here are some comments:
Environment - the description in the BPC admin client can, the technical name on the backend will be generated
Model - same as environment
Dimension - same as environment
Member Formulas - this is driven by member IDs
Input Screen - not sure what this is
Data Manager Package
Process Chain - the out of the box PCs are all in the CPMB namespace, the new ones just need to be copied in there but they wouldn't be created in BPC rather in BW
Hope this make sense,
Akos

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

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

Storage Location Naming Convention without WM!

Dear all
We are facing serious problem in our Storage Location for Raw Material.
We have 4 types of Raw Material Seating (S), Panel (P), Metal (M), Wood (W). And they are all stored under Storage Location: RWSL.
Requirement:
Although we have visual guideline as to which industrial rack will store the type of Material, it is insufficient. We need a more refined storage location down to which BIN of the rack we will put the Raw Material.
Due to limited time and resource, we cannot have WM implemented right now. Thus, we have come out with 2 alternative to overcome this problem:
Alternative 01:
We will use the Fixed Bin field in Storage Data 02 by putting the Bin number assigned to each Rack.
E.g. For Seating material code:SEAT01, we will maintain the Fixed Bin as R12A01/A02, it means this Seating material SEAT01 will be stored at Rack 12, fixed bin A01 or A02.
Question to Alternative 01: Will it cause problem in GR, GR, Transfer Posting and Stock Count?
Alternative 02:
Instead of going into details to put Fixed Bin field in Storage Data 2, we will abandan the existing Storage Location RMSL by introducing new format for Storage Location
Here is the example of Alternative 02:
For raw materials, we will use 4 digits location numbers, consistent with other Storage locations, the 4 digits storage location will start with u201CR _ _ _u201D to represent each location
And,
R _ _ _ is:
R = Raw materials
2nd digit = Division (S= Seating, P =Panel, W=Wood, M=Metal and W=Wood)
3rd digit = Rack Number (A, B, C, Du2026 and etc.)
4th digit = Rack Zone - each rack will broken down into zone, each rack can possibility have 2 to 3 zone. 1 Zone can be 1 colume of the Rack
An example of a possible location and its meaning will be
RSA1 = Raw materials warehouse, Seating division, Rack A, Zone 1
RPB3 = Raw materials warehouse, Panel Division, Rack B, Zone 3
The challenge of this is that instead of having 1 Raw Material Storage Location like RMSL, we will have a lot more storage locations each for division of Raw material due to the Rack Number we have as well as the Rack Zone.
Question to Alternative 02:
If we use this alternative, will it impact our future implementation of WM? From design wise, is it feasible?
Please advise what is the best approach and the feasible design on it.
Many thanks in advance.
Edited by: Daimos on May 13, 2009 10:15 AM

Hi, here is the Pro and Co of both approaches:
Method 01: Use existing SLOC and add the Storage Bin info
e.g. SLOC: STM1
         Storage Bin: RSC3, where RS = Rack Seating, C3 = column 3
Pro 01:
It will cause less effort as we only need to use LSMW for material master to add in the Storage Bin data for all material of SCM.
Pro 02:
I have tested out that in TCode MIGO, apart from SLOC, the pertaining Storage Bin data also appear. Based on my discuss with Xian Chen, sometimes they use MB1C(GR), MB1A(GI) rather than MIGO due to speed issue, I will need to check the field status if can have Storage Bin field APPEAR, if can, it will solve the problem
Con 01:
The Storage Bin information will only appear in MMBE (Stock Overview) but will not appear in the standard SAP Inventory Report (e.g. MB52 Warehouse Stock). To view it from SAP Inventory Report, we may need to customize the standard report to show the new field Storage Bin. It needs Abap effort.
Con 02:
We must have a very good naming convention for Storage Bin. And again, in the above example, if a material is put in SLOC STM1 at Storage Bin RA A1 or C4, it will set a very rigid rule in the future if we need to change it, as I fear that one the Storage Bin has been used up. It will not allow us to change (need to do testing to find out)
Con 03:
Do we have the time to define all the Storage Bin for each SLOC? Operation wise, the store personnel needs to design it
Method 02: Use the new SLOC
Pro 01:
RSA1 = Raw materials warehouse, Seating division, Rack A, Zone 1. More organized. Easy to tell the material is at which Rack and which Zone of the Rack.
Assumption:
01. we must not have too many rack for one Seating division and also not too many Zone for each
      Division, else it will cause confusion
02. 1 material should stick to 1 Rack 1 zone as much as possible, else later the PP consultant will
     have hard to to perform GI due to too many SLOC assigned to a material.
Pro 02:
In report wise, we are able to show the SLOC in inventory report. No need to enhance the existing inventory report as we do not use Storage Bin.
Con 01:
If there are too many SLOC creation due to it. It may cause problem for PP perform GI as too many selection available for a material. This can be avoided if stick to the General Rule that one material is tied with one SLOC.
Edited by: Daimos on May 16, 2009 5:07 AM

Powershell naming conventions for functions

There is a lot of information about the Verb-Noun naming convention for cmdlets. I am trying to understand what the recommendation / best practice is for naming functions. Personally, I like the idea that if I see Verb-Noun, I know it's
a cmdlet, and it supports the standard parameters. However, I'm not sure I see the entire picture.
Thanks!

There are as many opinions around this as there are people. TechNet has some good recommendations for naming conventions, but you should adopt whatever standard you are most comfortable with. In the end it doesn't much matter which convention
you adopt, as long as you stick to it and keep it consistent. Most corporate code doesn't get outside or shared with other businesses and vendors, so the whole purpose of standards and conventions is to keep things straight for YOUR people. As
long as you consistently apply your conventions, it doesn't matter.
I trust that answers your question...
Thanks
C
|
RSS |
http://crayveon.com/blog |
SharePoint Scripts | Twitter |
Google+ | LinkedIn |
Facebook | Quix Utilities for SharePoint

Naming conventions, corporate governance standards, etc.

Similar Messages

Maybe you are looking for