Interface naming convention - HasA relationship

Hi all,
I have been wondering from time to time how to name interfaces that declare a "has-a" relationship.
Let's consider this:
I have a class - Company - it has many things a company can have.
Now I have Deal, Invoice, Document, Shipment and other classes that can have a Company as their property. I want to be able to ask every one of them to tell me their Company.
How to name the interface that will have this method:
public interface Company...{
public Company getCompany();
}Somehow I don't feel comfortable with Companyable, on the other hand HasACompany is no good because sooner or later I will end up with lots of HasASomething interfaces.
I searched around, read some code convention guidelines, found some threads about naming interfaces (like http://forum.java.sun.com/thread.jspa?forumID=31&threadID=495341), but still I have no solution.
Please guide me in choosing the proper convention for naming such interfaces in the future
Mike

Dave, you are right, my example was no good.
I also agree that it is not good to mix usage cases. It is also true that in most cases I have hierarchies that have some common usage of a company and I can tell why they have a company. But I don't want to have several interfaces, all of which provide access to the same property but with different names.
What I would like to achieve is something that is close to the OpenOffice services concept. In OpenOffice you can query some object for some interface and if the service is provided you can get implementing instance.
I am not quite sure but you can get XWindow from document, or from an internal frame, or who knows from what else.
What I want to achieve is to say "Something that has this certain property" without caring beforehand why I want to know this.
On the other hand I cannot prove that the design is "correct". I am just curious how an interface that describes a certain service/property would be named in a good way.
Thanks for info
Mike

Similar Messages

Naming convention best practice for PDB pluggable

In OEM, the auto discovery for a PDB produces a name using the cluster as the prefix and the database name suffix, such as:
odexad_d_alpcolddb_alpcolddb-scan_PDBODEXAD
If that PDB is moved to another cluster, I imagine that name will not change but the naming convention has been violated.
Am I wrong and does anyone have a suggestions for a best practice naming the PDB's

If the PDB moves to another cluster, OEM would auto-discover it in the new cluster. So it would "assign" it a new name.
As a separate question, would you be renaming the PDB (the physical name) when you move it to another cluster ?
Hemant K Chitale

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

Someone has nomenclature (naming conventions) for oracle data integrator?

Someone has nomenclature (naming conventions) for oracle data integrator?

You should really move this question over to the Oracle Data Integrator forum(Data Integrator for a more expedient response.

Flatfile conversion with output file has a NAMING CONVENTION

Dear SAP experts,
I need some advise regarding my scenario.
I am converting a message into flatfile. (customized .csv)
But, the output .csv flatfile must have a naming convention.
E.g. Globus_20071020 (Customer name_YearMonthDate)
Can somebody give me ideas/inputs on what will I configure in File Receiver (FCC) in order to have an output file having a naming convention indicated above.
Or do i need additional configurations?
Please advise.
Thank you very much in advance.
Fred

Hi,
You could pass this kind of File name from mapping at runtime or
You could use the variable substitutions to create the fiel neame as per naming convention as adding date .
With reference to Variables youcould set file name as Globus_%payload.<Date>%
Pass the value in date field of payload
Refer
Variable Substitution
How to use Variable substituion
/people/sameer.shadab/blog/2005/09/23/an-interesting-usage-of-variable-substitution-in-xi
/people/sravya.talanki2/blog/2005/08/11/solution-to-the-problem-encountered-using-variable-substitution-with-xi-sp12
how to use attributes in variable substitution???:(
Dynamic file name
/people/jayakrishnan.nair/blog/2005/06/20/dynamic-file-name-using-xi-30-sp12-part--i --> Dynamic File Name using XI 3.0 SP12 Part I
/people/jayakrishnan.nair/blog/2005/06/28/dynamic-file-namexslt-mapping-with-java-enhancement-using-xi-30-sp12-part-ii --> Dynamic file name(XSLT Mapping with Java Enhancement) using XI 3.0 SP12 Part -II
Dynamic File name in File adapter
/people/michal.krawczyk2/blog/2005/11/10/xi-the-same-filename-from-a-sender-to-a-receiver-file-adapter--sp14
1. In the sender file adapter , select Adapter Specific Attributes --> FileName.
2. Use the code in this link to read the filename inside a UDF in your mapping.
DynamicConfiguration conf = (DynamicConfiguration) container
.getTransformationParameters()
.get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);
DynamicConfigurationKey key = DynamicConfigurationKey.create(
http://sap.com/xi/XI/System/File,
FileName);
String filename = conf.get(key);
http://help.sap.com/saphelp_nw2004s/helpdata/en/43/03612cdecc6e76e10000000a422035/content.htm
Thanks
Swarup

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

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.

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

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

Looking for best practice on naming conventions

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

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

Interface naming convention - HasA relationship

Similar Messages

Maybe you are looking for