Enhancements Naming Conventions - Recommended

Hi All,
Can somebody suggest me the Recommended Naming Covention for:
1. Project
2. Business Add-In Implementation
3. Composite Enhancement Implementation
4. Composite Enhancement Spot
5. Enhancement Implementation
6. Enhancement Spot
Thanks,
Prashant Singhal

It really does depend on the project. Each project has its own defined standards but some examples are below.
Datatype: DT_
Message Type: MT_
Message Interface: MI_<Async/Sync>_<Direction>_
Message Mapping: MM_<SourceMessage>_<TargetMessage>
Message Interface: IM_<SourceMessage>_<TargetMessage>
Communication Channels: CC_<AdapterType>_<Send/Recv>_
Integration Process: IP
These are just a few and should give you some idea... but the main thing is to make sure they are always meaningful and easily distinguishable.
But as I said each project has its own flavour

Similar Messages

IP Naming Convention Recommendation

Hello all!
Do any of you have a recommendation on how to name agg levels, filters, functions, sequences, and queries in IP?
Thanks
T

Hi Tim,
I have put together a naming standard for my IP project and it is approximately:
where ff is the functional area
         nn is a number for cubes, aggregation level, etc.
         mm is a sequential number for filter, functions, sequences, etc.
         xxx os a sequential number for queries, layouts, WAD templates.
ZIPff_Cnn - basic cube
ZIPff_Pnn - Planning / Realtime Infoprovider.
ZIPff_Onn - ODS
ZIPff_Mnn - Multi-Provider
ZIPff_Ann - Aggregation Level
ZIPff_Ann_FIL_mm - Filter
ZIPff_Ann_PF_mm - Functions
ZIPff_Ann_PS_mm - Sequence
ZIPff_Ann_Qxxx or ZIPff_Cnn_Qxxx - queries / reports
ZIPff_Ann_Lxxx - input enabled query Planning query / layout
ZIPff_Ann_Wxxx or ZIPff_Cnn_Wxxx - WAD template, etc.
If you want more specifics, E-mail me.
Cheers,
Mary

Help on error message: Naming convention for menu enhancements not observed

Hi all,
I was trying to enhance a transaction and got into entering function code without following naming conventions (i.e. function codes should start with '+'). It is not allowing me to change it by throwing an error "Naming convention for menu enhancements not observed".
This question was previously posted in the thread -- Re: Error in SMOD ?
which was not answered. Can you help me in resolving this error or revert my modifications that I have done while enhancing?
I appreciate any help in regard.
Thank you,
Deepak

You shouldn't get this message if you just create the implementation. I feel that you are trying to change the definition part of the standard extension, using SMOD transaction. That's bad
If you want to enhance, create a project using CMOD transaction, enter the extension name, then simply double-click the +... function code and enter your text.

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

File name naming convention in File Adapter configuration in ID

Hi All ,
I have a query related to xml filename created in IDOC-XI-FILE scenario based on value of one of IDOC field .
The scenario is like this :
I have to send one xml file per store for material master . In this case how can I define my file name with store name in File adapter configuration in ID .
Naming convention should be
<storename>_date_masterdataname.xmlwhere store name is one of field of IDOC .
Plz help me .
Thanks in Advance
Regards
Prabhat Ranjan

Hi Prabhat,
take a look at this weblog:
/people/jayakrishnan.nair/blog/2005/06/28/dynamic-file-namexslt-mapping-with-java-enhancement-using-xi-30-sp12-part-ii
you have to specify variable substitution
(in the file adapter)
and give the path to the store name (in the variable sustitution table)
you file name schema (from the file communication channel can look like this)
%storename%_date_masterdataname.xml
Regards,
michal
Message was edited by: Michal Krawczyk

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

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.

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

SAP Naming Conventions for DB Data Files

Hi Everyone!
We are about to install a SAP ECC 6.0 SR3 ABAP on Windows Server 2008 (R2) & SQL Server 2008 SP1 and we want to name the DB data files as follows:
<sid>DB_Data_001.MDF/NDF
Do you see any problem with this or think this could lead to a problem in the future?
We were unable to find a SAP note or SAP recommendation about this, we only found SAP Note 27428 but itu2019s for Oracle.
Thanks in advance!
Best Regards,
Nicolas

Hi Nicolas,
I thought about all corners where this could possibly lead to a problem (e.g. monitoring, DB13, ...) but couldn't think of a single report or transaction where this would cause problems.
To the database itself the names of the files do not matter at all and in the SAP transactions the datafiles are only read to display them in monitoring transactions like DB02 or RZ20. These transaction do not expect a certain naming convention so I don't see anything that would count against using different filenames.
Regards,
Beate Grötschnig

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

Best Practices for farm naming conventions

Hi
I wanted to get some basic best practices and recommendations for farm naming conventions when setting up multiple farms in our environment.
what are the do's and don'ts?

First, figure out why you need multiple farms :-)
I generally name machine accounts based on purpose and location, with a numeral. For example, a SharePoint server in Redmond might be:
REDSP01, REDSP02, REDSP03...
And a SQL Server dedicated to this SharePoint farm might be:
REDSPSQL01, REDSPSQL02...
If using a SQL cluster, I might use:
REDSPSQL01A, REDSPSQL01B...
Trevor Seward
Follow or contact me at...
&nbsp&nbsp
This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Code Inspector - Naming conventions &mExtended Naming conventions for Progs

Hi experts,
I had a look into the naming conventions enforced by 'DEFAULT' variant of code inspector (SCI).
the relevant categories are: "Naming Conventions", and "Extended Naming conventions for Programs" under "Programing conventions".
in the "Extended Naming conventions for Programs" category, for functions, (applicable while calling the functions) it says,
importing parameter : I[:type:]_
exporting parameter : E[:type:]_
changing parameter : C[:type:]_
tables parameter : T[:type:]_
but in the "naming conventions" category, for functions (applicable while defining the functions), it says,
importing parameter : P_*
exporting parameter : P_*
changing parameter : P_*
tables parameter : P_*
I felt, while defining the function too, its better to have beginning with I_, E_, C_ or T_ instead of P_
is the 'DEFAULT' variant of code inspector is provided and recommended by SAP?
for easier maintenance and clearer understanding, which naming convention is more suitable, or is there any official guidelines released by SAP for ABAP developers.
appreciate the opinions from experienced abap developers.
thanks,
Madhu_1980

Frank,
Thanks for your answer.
But what about Entity Objects, View Objects, View Links, and Application Modules.
I would like my developers to have an easy way to name them and also find them via intellisense.
So I was thinking in naming them the following way :
Entity Objects :
EO_Employee
EO_Department
View Objects :
VO_Employees
VO_Departments
View Links :
VL_EmployeesToDepartments
Application Module :
AM_HRService
However the use of "_" is not so "Java naming oriented".
So other alternatives would be:
1. take the "_" :
1.1 EOEmployee (I don't like the fact of having 3 capital letters together).
1.2 EoEmployee (I don't like the fact of having Entity Object with a lowercase "o").
2. Use the prefix at the end, but this way I loose the intellisense feature I want:
ex: EmployeeEO
Which naming approach are you using for big projects ?
Thanks,
Claudio.

PI SWC Naming convention

Hello, I've read this SAP [document|http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/40a66d0e-fe5e-2c10-8a85-e418b59ab36a] about best practices naming convention and I still don't have a clear idea about how many software components I have to create in 1 scenario.
There are 3 posible ways in the document:
- 1 SWC with all the ESR objects - Not recommended.
- 2 SWC one with the receiver objects and the other with the sender objects. But where you keep the mapping objects??? Always in the sender SWC? Always in the Receiver???
- 3 SWC with receiver, sender and mapping objects respectively. I don't like that solution because I think that the SWC object loses its meaning and you will have all the objects of a simple scenario "spreaded" along the ESR.
Have you an better alternative to help me???
Best regards,
Marshal

Thank you for your answers.
It looks like it's really personal to decide which its the better option to define the SWC. I will think about it...
To Madhusudana Reddy and abhishek salvi: I think that organization way it's very clear but if you do that, the SLD is meaningless, because you are using a SWC as a "business area" not as a software, and I'm not sure about it. Maybe the problem is how the SWC object is used in SAP PI.
To Patrick Koehnen: I think that the 3 SWC approach is too much confusing too, and the 3rd SWC with the mappings it's not really a "software" of our landscape....

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

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

Enhancements Naming Conventions - Recommended

Similar Messages

Maybe you are looking for