Naming Convention (Fc) - ESS Business Logic Components

Hi Gurus,
Why does SAP name components with pre-fix 'Fc' as in <b>Fc</b><i>ComponentName</i> while naming Business Logic Components in ESS?
What does 'Fc' stand for?
Thanks,
Anjana R.

Hi Gurus, Any ideas?
Anjana R.

Similar Messages

2 Logical Components for 1 Business Process Step

Hello All,
I'm looking for a way to assign in SolMan --> transaction Solar01 - Tab Structure - Business Process Step, 2 logical components for 1 business step. When creating the business step I have to assign 1 specific logical component to this step. Once I have done this I can only select the chosen logical component ffor SAP Transactions, configuration object etc.. As my business step is running on 2 different systems I need to find a way to link transactions etc. in the step to the different systems. Is there any way to change this for the Level 3 elements, like it is for level 2 (business processes) where I can choose in the different tabs between all the logical components?
Thanks in advance
Ramó

I've seen people use some absolute craziness to get more than three levels. The most extreme being using multiple projects at the highest level (i.e. a project for PTP Accounts Payable). Don't go there.
I personally like to have 1 transaction per process step. Don't use the transaction tab as another process level, use it to better describe the process step (like all the other tabs are uses). It results in a better understanding of the system as you go forward. To do that I make teams break up things they think are one step (this can take some arm twisting, so hit the gym and maybe take a few judo classes).
This allows you to use SolMan in more powerful ways. For instance, if you attach development objects to a step with 5 transactions, you cannot tell which transaction is modified by the development object. However, one transaction per node provides you this link. There are other examples, but basically the "where used" button becomes very useful when you have 1 transaction per node.
Maybe you could provide a specific example of your process and we can think of a better way to collapse it.
Such as:
- PTP Non-Merchandise Purchasing
-- Expense Purchasing
--- Create Purchase Requisition
--- Create Purchase Order (Assign Vendor & Price)
--- Send to Vendor
--- Post Goods Receipt
--- Perform LIV
--- Process Payment
Some companies have 6 level processes already defined in models and putting it into SolMan can be a pain for sure. Your naming convention is usually the best route.
regards,
Jason
The system role and template work around doesn't apply to your situation.

Bean containing both UI components and business logic

Hello ADF design experts, please guide me.   I came across a critical design aspects. I have main page having bunch of UI components,   Region 1, Region 2. I will have to bind the UI components of the page to a managed bean having session scope and the reason is, when control goes to region 1 or region 2, I will be doing lot of processing of business logic and then based on this, I will have to update the UI components of the page.   Same thing with region 2 also. And then, I should be able to access the information    across regions and also across other UI components etc.
I am seeing only session scoped bean will be able to help me here to get my tasks done across regions and across all other UI components of the page because I am not in a position to pass too many parameters across regions.     Now the problem is, I can not serialize this bean because as I mentioned lot of UI components are updated based on logic.
If I do not serialize the bean, I may have problem in future when application has to be deployed to cluster envt.
I do not know how should I go with my design now.   Please provide me brilliant ideas and very thankful to your guidance.
thanks

Hi ADF,
I dont want to disturb the discussion with you and Alej. I'm rising some question from your first post.
I have main page having bunch of UI components,
ok fine.
Region 1, Region 2. I will have to bind the UI components of the page to a managed bean having session scope
1.why need to do this binding for all ui components .?
2.this question lead ask another question are you using ADFBc.? if so binding layer will take care why you bind all those things.
3.why you need to put session scope.?
if you are using region. the region can only be bounded TF right, then communicate with help of pageflow. inside the bounded you may have jsff/jspx,
reason is, when control goes to region 1 or region 2, I will be doing lot of processing of business logic and then based on this, I will have to update the UI components of the page.   Same thing with region 2 also.
from the reason i have question? why you need to communicate between two region instead of using Taskflow communication.
And then, I should be able to access the information across regions and also across other UI components etc.
ok fine.
I am seeing only session scoped bean will be able to help me here to get my tasks done across regions and across all other UI components of the page because I am not in a position to pass too many parameters across regions.     Now the problem is, I can not serialize this bean because as I mentioned lot of UI components are updated based on logic.
from my point of view. your are using all powerful feature session bean, region communication to do your requirement.
mixing all those things so only you can't able to get consistent results.
I do not know how should I go with my design now.
could you please explain your usecase.
Please provide me brilliant ideas and very thankful to your guidance.
yeah sure. people will do.
thanks

How to get Custom Time Correction business logic implement for ESS in R/3?

Hi Experts,
I am in trouble of implementing the custom requirement of correcting the time in ESS. I have to implement the time corrections as per business logic.
Can any body tell me where to do this?
What I need is suppose employee DWS is from 9:30 AM to 6:00 PM and suppose he forgot to punch the In time and then corects the entry for 9:30 AM in ESS then it get inserted into the R/3 data but now requirement is if support the employee has punched but at 10:00 AM and then corrects to 9:30 AM then it does not change the 10:00 AM and we wanna deleted these 10 AM entry.
Thanks in advance.

I have solved by created enhancement spot in PT_COR_REQ
for method IF_EX_PT_COR_REQ~POST_VIA_BLOP
Regards,
Gaurav Patwari

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

Expert's advise: share EJB components and business logic

Hi all,
I've a J2EE applicacion and I want to know if is posible share my ejb business logic with other components in other enviroments and differents programming languages.
for example, I show you my scenario...
I've a J2EE application that will be run in a WebSphere server (running over windows) for my JSP cliente side(you know... the web browser), all is ok!!! but my application need also receive request from remote clients (components from other business applications) that may be compiled in .net (over windows) or c++ (over AS400 or linux) and send the response to the respective client.
well...
my question is if is posible, which can be the protocols or java technologies that i will need to use for implements some like this.
thanks for your answer...

Web services is one possibility.

Components naming convention

Are there any components naming convention guidelines? For example, for text field components id, should that be prefix with textName or suffix with nameText, etc. In tutorials, I have seen both approach.

We compiled some conventions based in engineering input. You can see them at http://developers.sun.com/prodtech/javatools/jscreator/learning/tutorials/2/about_components.html#general (see the id row in the table).
In the tutorials, we decided to not strictly follow these guidelines. Our reason was, we wanted the reader to focus on the lesson on hand. We didn't want to waste the users time renaming ids when it didn't really affect the outcome. These are one-time apps and thus the naming of the ids is not as important as with an app that will be worked on by different people over a span of time. Hope that makes sense.

Naming convention for Swing components?

What are the official naming conventions for Swing components such as JButton, JFileChooser and so on?
I know that "btn" is used for JButton variables. But where is a official list for all the prefixes?

Well, if you unpack src.jar and consult the component classes you'll find how they set up their names.
You can also call setName yourself to set a different name.
- David

BO Business Object Naming Convention

Hi experts,
we are about to implement SAP Business objects (previously using only using SAP BW). As part of the implementation we are creating a naming convention / standard for Webi and Universe. Is there anything published on SDN or the web regarding naming conventions / standards or is anyone willing to share some tips.
BR
Anders

Hi Anders,
In regards to naming your universe objects, please take a look at my blog post re Universe Best Practices (Link: [http://geek2live.net/posts/universe-design-best-practices/]).
I would always recommend naming universe objects (classes, dimensions, measures etc) in business terminology and being explicit in the definition. For instance, an object called 'Sales' could be interpreted many different ways. Is it Sales Revenue, Count of Sales Orders, Count of Sales Order Lines, Average Sales Amount, etc etc?
Your universes should also be named explicitly so users understand exactly what it contains. Another example - a Finance universe could contain many things - is it General Ledger Actuals, General Ledger Budgets, Fixed Assets, Accounts Payable etc..
The most important thing imho, is to define a standard that everyone who is designing universes uses, without exception. Otherwise the standards don't mean anything to the end users.
Good luck!
Josh

ADF BC naming convention suggestions

Ok, I havent found too many topics on this matter, but here is a list of naming conventions our team is debating over. I would also like to hear the rest of the community's thoughts.
Entity: Use underlying table's name and postfix with Eo. If the table is a W view, it should prefix with W.
eg. EmployeeEo, WEmployeeEo
View Object (Single entity based): Use the Entity's name postfix with Vo.
eg. EmployeeVo, WEmployeeVo
View Object (Multiple entity based): Use the primary entity's name followed by a "busniess task" name.
eg. DepartmentEmployeeSearchVo (employee search being the task).
View Object (Non-entity based): Use the primary query table name followed by a "busniess task" name.
eg.EmployeeCountVo
View Link & Association: Combine the master entity name and child entity name postfix with Vl/Ao.
eg. DepartmentEmployeeVl, DepartmentEmployeeAo
(The issue with this is our legacy tables are not that intuitivly named, so its hard to distinguish the master/child tables. I was thinking of splitting it with lets say 2, like Department2EmployeeVl)
Application Module: Apply a "busniess process" name and suffix with AppModule.
eg. AcmeAccountingAppModule.
If anyone has any suggestions or see any conventions left out please post them.
Thanks,
Z

Without discounting your object name conventions, don't forget the Java package they are placed in helps gives context for the object. This is what I tend to do:
com.acme.appmodules
com.acme.entities (all entities)
com.acme.entities.associations
com.acme.views (common VOs)
com.acme.views.links (common VO links)
com.acme.views.reference (common read only VO lookups)
com.acme.views.<business task> (to group logical business VOs together)
com.acme.views.<business task>.links
...the last 2 are repeated for each business task area (eg. HR, accounts, etc)
My ideas partially based on the SRDemo from the JDev team.
Hope this helps.
CM.

Naming convention for packages and classes

Hi all,
Is there any naming conventions for packages and classes which uses a design pattern ?. If yes what are the conventions used for business delegate,session facade, service locator,DAO and any other patterns.
rgds
Anto Paul

Hi,
that is a good question and one we have considered also. We dont yet cover the naming conventions for classes based on patterns but maybe will in the future. Currently, in the blueprints apps we tend to do some things like naminga class
-AccountDAO etc for DAOs
-For servicelocator we have a class called ServiceLocator viewable at https://adventurebuilder.dev.java.net/source/browse/adventurebuilder/ws/components/servicelocator/src/java/com/sun/j2ee/blueprints/servicelocator/web/ServiceLocator.java?rev=1.4&content-type=text/vnd.viewcvs-markup
-for session facade, its a bit trickier since the name is so long and we cant add "SessionFacade" to the end of each facade class. I think in general we put "Facade" in the name, usually near the end
-For Business Delegat, again it seems too long to add to each class name. So in the past we have added
a "BD" to the names of the delegates. Some examples are at http://java.sun.com/blueprints/patterns/BusinessDelegate.html
-For transfer objects we usually add a TO to the end of the name. Some examples at http://java.sun.com/blueprints/patterns/TransferObject.html
Seems like something we could get a bit more consistent about.
hope that helps,
Sean

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....

[svn:fx-3.x] 12371: The main AccImpl was updated to handle accessible naming conventions differently than before .

Revision: 12371
Revision: 12371
Author:   [email protected]
Date:     2009-12-02 08:51:12 -0800 (Wed, 02 Dec 2009)
Log Message:
The main AccImpl was updated to handle accessible naming conventions differently than before. This change was made to make the 3.x branch consistent with the trunk changes. The updated methods allows the accessibilityName property to overwrite the logic that was previously used to build the accessible name for components that were inside of forms. This method also provides a method to allow developers to specificy that no form heading or form item label should be included in the accessibilityName for the form field by using a space.
QE notes: none
Doc notes: none
Bugs: n/a
Reviewer: Gordon
Tests run: checkintests
Is noteworthy for integration: no
Modified Paths:
    flex/sdk/branches/3.x/frameworks/projects/framework/src/mx/accessibility/AccImpl.as

Revision: 12371
Revision: 12371
Author:   [email protected]
Date:     2009-12-02 08:51:12 -0800 (Wed, 02 Dec 2009)
Log Message:
The main AccImpl was updated to handle accessible naming conventions differently than before. This change was made to make the 3.x branch consistent with the trunk changes. The updated methods allows the accessibilityName property to overwrite the logic that was previously used to build the accessible name for components that were inside of forms. This method also provides a method to allow developers to specificy that no form heading or form item label should be included in the accessibilityName for the form field by using a space.
QE notes: none
Doc notes: none
Bugs: n/a
Reviewer: Gordon
Tests run: checkintests
Is noteworthy for integration: no
Modified Paths:
    flex/sdk/branches/3.x/frameworks/projects/framework/src/mx/accessibility/AccImpl.as

BPC Standard Naming Convention

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

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

XML Schema Component Naming Convention

Is there a naming convention when you create an XML Schema? For example,
When you create a Type component, then the first letter of its name should be upper case ie. BMW, Honda, AutombileEngine ...etc.
When you create an Element component, then the first letter of its name is lowercase ie. engine, car, guestCar ..etc.
Do we have such naming convention for XML Schema?
Thanks

I am giving this from my document which i prepared for one of my customer
2     General Guidelines for design of XML schema documents
The representation of data in an XML format will be a key component of development within SOA. Therefore, the design and development of XML schemas should be as rigorous an activity as designing and developing code or designing database schemas. As such, when creating an XML schema you should be working within a development process and working to a set of design guidelines and coding standards (when writing the XML schema file). XML schemas should be reviewed for accuracy and compliance with guidelines and standards. Each of the requirements in the list below is a general requirement for all XML schemas to be deployed in the SOA environment.
•     Understandable: XML schemas should be clear, consistent and unambiguous. They should contain human readable documentation and, where appropriate, links to requirements or design documents.
•     Semantically Complete: An XML schema should define, for one or more target XML documents, each and every element and attribute that is understood by your solution when processing target documents.
•     Constraining: XML schemas are used as contracts between both publisher and consumer. As such, they must be able to be validated as concisely as possible. When designing an XML schema constraints should be identified for the values for all the elements and attributes that the application uses and relies on to the set of values that the application can handle. A valid document should imply valid data within the limits of what can be specified by the XML Schema language.
•     Uniquely identifiable: XML schemas should import and include other XML schema files rather than duplicating types and elements locally.
•     Reusable: XML schemas should be specified in such a way that types and other XML schemas can leverage elements. Every type defined in an XML schema that is the content type of an attribute or an element should be defined globally (i.e., at the top level in the Schema). Types that are defined globally can be reused in other XML schemas. Schemas should be separated into logical sections which can be included into the main schema file.
•     Extensible: Schemas should be designed to be extensible—that is, new elements and attributes can be inserted throughout the document.
Every schema should use at least two namespaces – the targetNamespace and the XML Schema (http://www.w3.org/2001/XMLSchema) namespace.
Create typed elements that can be referred to by object elements:
Example:
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.soa.com"
xmlns="http://www.soai.com"
elementFormDefault="qualified">
<xsd:complexType name="PersonType">
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="SSN" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.company.org"
xmlns="http://www.company.org"
elementFormDefault="qualified">
<xsd:include schemaLocation="Person.xsd"/>
<xsd:include schemaLocation="Product.xsd"/>
<xsd:element name="Company">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/>
<xsd:element name="Product" type="ProductType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
•     Recognize that with XML Schemas you will not be able to express all your business rules.
o     Express those business rules using XSLT.
•     Use type definitions
Elements vs Attributes
•     Use attributes for metadata about the parent element.
•     Use attributes for data that is semantically tied to the enclosing element.
•     Use elements for data that have a meaning separate from the enclosing element.
•     Use attributes when the value will be frequently present in order to improve the human readable form of an XML instance document or reduce its size.
•     If you don't know which to use, then use the element form (which is more extensible).
2.1.1     Element, Types and attribute names
Create a descriptive name without it being excessively long (no more than 32 characters).
Elements and Types should be named in Upper Camel Case. Upper Camel Case capitalizes the first character of each word and compounds the name (remove all whitespace).
Attributes should be named in Lower Camel Case. Lower Camel Case capitalizes the first character of each word except the first word and compounds the name.
Simple and Complex type names
XML Schema has separate symbol space for elements and types so they may have the same name. The best practice is to append the word "Type" to all simple and complex type names to aid in human readability and comprehension.
Element, attribute and type names MUST be in a singular form unless the concept itself is plural.
2.1.1.1     XML Schema versioning
Use major and minor version tracking:
Major—completely different structure and semantics, most likely not backward compatible
Minor—backward compatible changes which introduce new features without removing or changing the semantics of existing structures
2.1.1.2     Indication of version in the namespace URI
Specify a namespace URI as follows
http://$domain/$groupSpecifier/$namespaceTitle/$version
The groupSpecifier can include several levels, e.g., /www.soa.com/SOA/USA/.
An example namespace could be:
http://www.soa.com/SOA/order/2

Naming Convention (Fc) - ESS Business Logic Components

Similar Messages

Maybe you are looking for