Naming convention concerning interfaces?

Our trainer suggested to use the naming convention ifa for interfaces, for example ifaCar or ifaTree.
Does this make sense?
Please answer as many as possible.

What does an "ifaCar" do? It should describe what it does. So any class that implements "Printable" can be printed.
Meaning it does not really matter if you name it "ifa..." just to know it is an interface.
cheers
Jonas

Similar Messages

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.

Hard to find ripping naming conventions

?In Mediasource Player 3.3, I had a really hard time finding the naming convention settingsdialog. It is in the media folder format settings option. I ended up with a bunch of ripped tracksthat had the track name twice and couldn't find the option. Hopefully this thread will help someoneso they don't have to struggle as much as I did. In the Settings pop-up the PC Music Library tab,and the Properties button under the first item which is the name of your current PC Music libraryname. I had failed to change the last box on the bottom right from track name to none. Ta paj692

I guess the argument against your argument is that your code should be as self-documenting as possible. In your code, I'll see "Event". Great. java.awt.Event? No (annoyance #1 already). Your base Event? I wouldn't know, need to check the imports first. Aaahh, scrolled up and saw: your special implementation Event it was. Although, I will not see that if I'm not familiar with your package structure and you're doing package imports.
Create packages for functional groups, otherwise you'll end up with loads of unnecessary public declarations because your helper classes are splattered all over the place and can't just rely on in-package visibility.
And by the way, using polymorphism properly like you don't seem to do, you'll screw yourself, because you'll in future have to do things like:
Event ev = new com.mystuff.special.implementation.Event();Because you can't import both the interface/superclass and the implementation. Congratulations.

Logical System Naming Convention

Hi Guruz,
Is it mandatory to name your logical system starting with SAP system name. I went through SAP Documentation for creating logical system, it says <sap system name>CLNT<client number>. I didn't put my SAP system name for the first part<sap system name> instead some random letters. I know this question may sound stupid but I am right now in the middle of the integration so, I don't want to change it. Please confirm.

I'm work for the customer who has ~4000 logical systems defined (not all represent SAP boxes though). Which I find quite a lot, yet given the rules of naming convention helps a lot.
I would say that having the system name should be used whenever we talk about Logical Systems representing SAP boxes. But in case of external non-SAP applications, it is helpful to represent them by the external system.
Say, you have 20 SAP installations, each sending interface to application A. Then it is easier to monitor in XI/PI interfaces for single receiving logical system 'A'. But if you want to find out messages from given sending SAP system, then using SAP system name is recommended to extract such data quickly.
Regards,
Dominik Modrzejewski

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

Best practices in Internal table naming convention GT , GS , LT , LS ??

Hi Gurus,
 Are GT_ , GS_ , LT_ , LS_ --- the Best practices in Internal table naming convention ????
 I have seen this naming convetions adhered in standard programs .
 What each one of the below signify
 GT_ , GS_ , LT_ , LS_ ???????
Regards
Jaman
Message was edited by:
 ABAP Techie

Hello
I use the following naming conventions:
- G = global variable
- L = local variable
- T = internal table
- S = structure
- D = field
That's how the combinations look like:
- GT_ITAB = global itab
- GS_STRUC = global structure
- GD_FIELD = global field
- LT_ITAB = local itab
- LS_STRUC = local structure
- LD_FIELD = local field
Function module parameters have to stick to the following rules:
- I = importing
- E = exporting
- [C = changing -> never used]
- IT_ITAB = imported table type (itab)
- IS_STRUC = imported structure
- ID_FIELD = imported field
- ET_ITAB = exported table type (itab)
- ES_STRUC = exported structure
- ED_FIELD = exported field
Depending on their semantics TABLES parameters look like:
- IT_ITAB = imported data
- ET_ITAB = exported data
- XT_ITAB = changing data (import & export)
Here are the conventions for FORM routine parameters:
- UT_ITAB = using itab (data are usually treated like constants; no changes will be transfer - although possible - to the calling program)
- CT_ITAB = changing itab (if it is semantically an exporting itab then one of the very
first statements in the routine is: REFRESH ct_itab. )
- US_STRUCT
- UD_FIELD
- CS_STRUCT
- CS_FIELD
Conventions for class/interface parameters:
- IT_ITAB = importing table type
- IS_STRUC = importing structure
- ID_FIELD = importing field
- ET_ITAB = exporting table type
- ES_STRUC = exporting structure
- ED_FIELD = exporting field
- RT_ITAB = returning table type
- RS_STRUC = returning structure
- RD_FIELD = returning field
Conventions for class/interface attributes:
- MT_ITAB = table type
- MS_STRUC = structure
- MD_FIELD = field
- MC_CONST = constant
Question: Are there any advantages of such elaborated naming conventions?
My answer to this question is: Yes, definitively.
I believe that the advantage of semantically differentiating TABLES parameters of function modules is quite obvious:
CALL FUNCTION 'Z_BAD_NAMING'
 TABLES
 itab1 = ...
 itab2 = ...
 itab3 = ... .
CALL FUNCTION 'Z_GOOD_NAMING'
 TABLES
 it_itab1 = ...
 et_itab2 = ...
 xt_itab3 = ... .
I also believe that my naming conventions clearly enhance readability and maintainability of my programs.
Regards
Uwe

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

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 - programmer refuses to stick to them... what to do?

A fellow programmer on my team, though good, often refuses to abide by naming conventions, or seem even to be aware that many have existed and use that knowledge accordingly.
Today, for example, he created a class (not an interface) called Createable. I pointed out to him that convention over the years has been that classes ending in '-able' were usually interfaces, or might be suspected to BE interfaces by other programmers looking at his code.
He said he didn't care.
I then later noticed he had an interface defined in another package called 'Createable'. So he had made two classes of the same name in different packages, one an interface and one not.
Our boss doesn't seem to mind this kind of thing (he just wants us to get the work done and isn't interested in quibbling over things like naming convensions). Perhaps I'm a bit stern about these kinds of things, but it really gets my goat when this happens.
What's your opinion, Java Community?
- Tim
Edited by: user2052552 on Feb 3, 2011 12:41 PM

user2052552 wrote:
A fellow programmer on my team, though good, often refuses to abide by naming conventions, or seem even to be aware that many have existed and use that knowledge accordingly.
Many conventions? As in your team doesn't have a convention but you want them to follow one which is unspecified?
Today, for example, he created a class (not an interface) called Createable. I pointed out to him that convention over the years has been that classes ending in '-able' were usually interfaces, or might be suspected to BE interfaces by other programmers looking at his code.
English is a limited language.
Is 'Manager' suitable for the name of a class or an interface?
If only the latter then what do I call a class that represents something that "manages"?
He said he didn't care.
I then later noticed he had an interface defined in another package called 'Createable'. So he had made two classes of the same name in different packages, one an interface and one not.
Our boss doesn't seem to mind this kind of thing (he just wants us to get the work done and isn't interested in quibbling over things like naming convensions). Perhaps I'm a bit stern about these kinds of things, but it really gets my goat when this happens.
What's your opinion, Java Community?First it is a management problem.
Second there are proven techniques for producing better code. Coding conventions are not one of those.
Third if an organization is such that it is using other proven techniques, then coding conventions might have some measurable impact on quality, but lacking other techniques (or lacking all techniques) there can be no measurable impact as it would be less than the noise level caused by other correctable items.
Fourth as a point about what measurable techniques are the classes that the developer is creating actually Objects (Object Oriented Objects)? Versus random collections of functionality for example? The latter would be a far more serious problem than naming. And does that developer, and all of the other developers, use inheritence appropriately? Again misuse there would be a far more serious problem.

Do you have suggestions for naming conventions within AIF?

Hi Folks!
Being new to AIF I'm currently in the information gathering phase for myself and colleagues as we are starting to think about implementing interfaces with the help of this toolbox. I already found and read (or at least skimmed!) through various of your discussions as well as the very helpful blog posts from Verena, Michal and Andrey.
One of the first things we want to do - before we really get started for real - is to come up with some feasible naming conventions for the various customizable bits and pieces like
Namespace
Interface Name
SAP Data Structure (if applicable?)
We also have some general questions:
Does it make sense to prepare for one namespace per SAP-module or is it better to have just one and do the separation on the Interface name "level"?
Is it preferred - even though SAP doesn't seem to enforce this - to start our own names with a "Z"?
Searching SCN for "naming convention aif" didn't find anything related and while scrolling through the discussion forum I also didn't see any titles which might go into this direction. In order for us to not re-invent the wheel - or to start off in the wrong direction - I'm hoping to get some helpful pointers from you.
Thanks much for any feedback you have!
Cheers from Germany
Baerbel

Hi Bärbel,
Your question is very good. We had the same and decided for following own approach:
Namespace
A Namespace is a concatenation of business process and SAP module, e.g. O2C_AR, P2P_AP, P2P_MM, R2R_GL.
We have one global namespace for global objects as checks on currency code, date format value mappings, etc.
Interface NameEvery interface has its own name. To be honest for inbound interface the names are more a user friendly description, for outbound we follow a little rule that they start with OUT_.
SAP Data Structure (if applicable?)
We try to do the structure mapping in the middle-ware and AIF is only responsible for the functional mappings.
The root structure name is different between raw data and SAP data. But the sub structure and field names are equal. Because of this we can use the move corresponding fields or in some only monitoring interfaces even move corresponding structures.
We also have some general questions:
Does it make sense to prepare for one namespace per SAP-module or is it better to have just one and do the separation on the Interface name "level"?Because AIF support and business users differ in different business processes we separated in these processes and modules. In addition the recipients groups are similar to the name spaces.
Is it preferred - even though SAP doesn't seem to enforce this - to start our own names with a "Z"?For namespaces (six characters) and interface names (10 characters) we don’t.
Best wishes
Christoph

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

Whats most common naming convention for MP3s (what does iTunes store use?)

Trying to organise all my tags and music.
I am using iTunes and some other tag (tag%rename) WMP etc, as some seem to not show all the tgs of other programs)
However what is the generalised, most common naming convention for MP3 files?
ie. track no, Album, artist etc.
Also Ive never bought music from iTunes store yet, only got podcasts and stuff, but when you do , what is the filename convention they use please?
cheers
Mac OS X (10.5) iMac 20" 2Ghz (1st ever Mac Comp)

iTunes has no automatic tag look up function for anything other than CDs (through GraceNote). I import a lot of mp3s (legally obtained) that need tweaking. Also, GraceNote doesn't provide lyrics. If I just need to edit a couple of tracks, the iTunes interface is fine. But for bulk adding of artwork or searching for release dates or lyrics, I use MpFreaker. I find it works best if you do small batches and keep an eye on what it comes up with. Sometimes, well, rarely, it's way off base.
There may be better utilities out there but MpFreaker was recommended to me by someone I trust who spends a lot of time reviewing such things and it works for me so I haven't looked for anything else. You might find more reviews of other software at www.ilounge.com
Best of luck.

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

Oracle Recomanded Naming Conventions for SOA

Hi,
We are working on a 12i implementation project using SOA (BPEL) for interface development and Oracle Data Integrator for conversion. Could you please let us know about oracle recomanded naming conventions for
1. Adapter Service
2. Adapter Connection Factories
3. Routing Services
4. XSD Files
5. XSL Transformation Files
6. ...etc
Is there any oracle corporation provided naming conventions document on these? If so please let us know. Your quick help would be highly appreciated.
Regards

If the names are meaningful (which will depend on what objects are in the different schemas) and the underlying architecture is reasonable, then the naming convention would be a good practice.
- How do the objects in the ABC schema relate to the objects in the ABC_ADMIN schema?
- What, exactly, does the _ADMIN suffix indicate?
My unfounded guess is that you have two related schemas because you're creating one schema that owns the objects and another schema that has restricted access to those objects (ideally just via procedures, functions, and views) for applications to use to log in. If that's the case, it's not obvious to me which of ABC and ABC_ADMIN would own the objects for the ABC application. But if you're actually separating the objects for other reasons, then _ADMIN may make perfect sense.
Justin

What are the naming convention rules for BAPI and types

what are the naming convention rules for BAPI
points will be rewarded,
thank you,
Jagrut BharatKumar Shukla

Hi,
plz go through the following links....
Business application Prograaming Interface is nothing but the Method of a Business object.
BAPI-step by step
http://www.sapgenie.com/abap/bapi/example.htm
list of all bapis
http://www.planetsap.com/LIST_ALL_BAPIs.htm
for BAPI's
http://www.sappoint.com/abap/bapiintro.pdf
http://www.sappoint.com/abap/bapiprg.pdf
http://www.sappoint.com/abap/bapiactx.pdf
http://www.sappoint.com/abap/bapilst.pdf
http://www.sappoint.com/abap/bapiexer.pdf
http://service.sap.com/ale
http://service.sap.com/bapi
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE8/BCFESDE8.pdf
http://www.planetsap.com/Bapi_main_page.htm
http://www.topxml.com/sap/sap_idoc_xml.asp
http://www.sapdevelopment.co.uk/
http://www.sapdevelopment.co.uk/java/jco/bapi_jco.pdf
Also refer to the following links..
www.sappoint.com/abap/bapiintro.pdf
www.sap-img.com/bapi.htm
www.sap-img.com/abap/bapi-conventions.htm
www.planetsap.com/Bapi_main_page.htm
www.sapgenie.com/abap/bapi/index.htm
Checkout !!
http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html
http://techrepublic.com.com/5100-6329-1051160.html#
http://www.sap-img.com/bapi.htm
http://www.sap-img.com/abap/bapi-conventions.htm
http://www.sappoint.com/abap/bapiintro.pdf
u can check the below the material also
what is BAPI?
BAPI stands for Business API(Application Program Interface).
I have answered this question before..
A BAPI is remotely enabled function module ie it can be invoked from remote programs like standalone JAVA programs, web interface etc..
You can make your function module remotely enabled in attributes of Function module but
A BAPI are standard SAP function modules provided by SAP for remote access. Also they are part of Businees Objest Repository(BOR).
BAPI are RFC enabled function modules. the difference between RFc and BAPI are business objects. You create business objects and those are then registered in your BOR (Business Object Repository) which can be accessed outside the SAP system by using some other applications (Non-SAP) such as VB or JAVA. in this case u only specify the business object and its method from external system in BAPI there is no direct system call. while RFC are direct system call Some BAPIs provide basic functions and can be used for most SAP business object types. These BAPIs should be implemented the same for all business object types. Standardized BAPIs are easier to use and prevent users having to deal with a number of different BAPIs. Whenever possible, a standardized BAPI must be used in preference to an individual BAPI.
The following standardized BAPIs are provided:
Reading instances of SAP business objects
GetList ( ) With the BAPI GetList you can select a range of object key values, for example, company codes and material numbers.
The BAPI GetList() is a class method.
GetDetail() With the BAPI GetDetail() the details of an instance of a business object type are retrieved and returned to the calling program. The instance is identified via its key. The BAPI GetDetail() is an instance method. BAPIs that can create, change or delete instances of a business object type
The following BAPIs of the same object type have to be programmed so that they can be called several times within one transaction. For example, if, after sales order 1 has been created, a second sales order 2 is created in the same transaction, the second BAPI call must not affect the consistency of the sales order 2. After completing the transaction with a COMMIT WORK, both the orders are saved consistently in the database.
Create( ) and CreateFromData! ( )
The BAPIs Create() and CreateFromData() create an instance of an SAP business object type, for example, a purchase order. These BAPIs are class methods.
Change( )
The BAPI Change() changes an existing instance of an SAP business object type, for example, a purchase order. The BAPI Change () is an instance method.
Delete( ) and Undelete( ) The BAPI Delete() deletes an instance of an SAP business object type from the database or sets a deletion flag.
The BAPI Undelete() removes a deletion flag. These BAPIs are instance methods.
Cancel ( ) Unlike the BAPI Delete(), the BAPI Cancel() cancels an instance of a business object type. The instance to be cancelled remains in the database and an additional instance is created and this is the one that is actually canceled. The Cancel() BAPI is an instance method.
Add<subobject> ( ) and Remove<subobject> ( ) The BAPI Add<subobject> adds a subobject to an existing object inst! ance and the BAPI and Remove<subobject> removes a subobject from an object instance. These BAPIs are instance methods.
http://help.sap.com/saphelp_nw2004s/helpdata/en/7e/5e114a4a1611d1894c0000e829fbbd/frameset.htm
http://www.sapgenie.com/abap/bapi/example.htm
http://help.sap.com/saphelp_46c/helpdata/en/9b/417f07ee2211d1ad14080009b0fb56/frameset.htm
http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html
http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html
http://techrepublic.com.com/5100-6329-1051160.html#
http://www.sap-img.com/bapi.htm
http://www.sap-img.com/abap/bapi-conventions.htm
http://www.sappoint.com/abap/bapiintro.pdf
http://www.sapgenie.com/abap/bapi/example.htm
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE8/BCFESDE8.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf
http://techrepublic.com.com/5100-6329-1051160.html#
http://www.sap-img.com/bapi.htm
http://www.sap-img.com/abap/bapi-conventions.htm
http://www.sappoint.com/abap/bapiintro.pdf
BAPI
http://help.sap.com/saphelp_46c/helpdata/en/9b/417f07ee2211d1ad14080009b0fb56/frameset.htm
http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html
Checkout !!
http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html
http://techrepublic.com.com/5100-6329-1051160.html#
http://www.sap-img.com/bapi.htm
http://www.sap-img.com/abap/bapi-conventions.htm
http://www.sappoint.com/abap/bapiintro.pdf
http://www.sapgenie.com/abap/bapi/example.htm
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE8/BCFESDE8.pdf
List of all BAPIs
http://www.planetsap.com/LIST_ALL_BAPIs.htm
http://www.sappoint.com/abap/bapiintro.pdf
http://www.sappoint.com/abap/bapiprg.pdf
http://www.sappoint.com/abap/bapiactx.pdf
http://www.sappoint.com/abap/bapilst.pdf
http://www.sappoint.com/abap/bapiexer.pdf
http://service.sap.com/ale
http://service.sap.com/bapi
http://www.geocities.com/mpioud/Abap_programs.html
http://www.sapdevelopment.co.uk/reporting/reportinghome.htm
***do reward if usefull
vijay

Naming convention concerning interfaces?

Similar Messages

Maybe you are looking for