Functional Areas

Question

What are functional areas? user groups? how does abap/4 query work in relation to these?

Answer 1

HI
functional areas
these are the Functional areas and you can get information in t his site
http://sapbrainsonline.com/TUTORIALS/FUNCTIONAL/
CA
CO
FI
HR
LO
MM
PM
PP
PS
QM
SD
TR
WM
user groups
Transaction SUGR - have a look. Purpose for example is to give certain system admin rights to unlock / change password only to a given user group. You assign user group to an user id via SU01.
User group can be used for different reasons and in different way.
In the latest versions of SAP, actually two types of usergroup exist, the authorization user group and the general user groups.
Naturally the main reason of user groups is to categorize user into a common denominator.
The authorization user group is used in conjunction with S_USER_GROUP authorization object. It allows to create security management authorization by user group. e.g. you can have a local security administrator only able to manage users in his groups, Help-Desk to reset password for all users except users in group SUPER, etc...
The general user group can be used in conjunction with SUIM and SU10, to select all the users in a specific group. User can only be member of one authorization user group but several general user group.
One of the Primary uses of user groups is to sort users into logical groups.
This allows users to be categorised in a method that is not dependent on roles/AG's/Responsibilities/Profiles etc.
User Groups also allow segregation of user maintenance, this is especially useful in a large organisation as you can control who your user admin team can maintain - an example would be giving a team leader the authority to change passwords for users in their team.
The most important factor identified is that the lack of user groups is an indication that there may be problems with the user build process. This is very "fuzzy" but is a bit of a warning flag.
The Auditors job is to provide assurance that SAP is set up and administered in a way that minimises risks to the financial data produced. If the only thing they have picked up on is the lack of usergroups then you will be fine.
If you are in any doubt whatsoever ASK THE AUDITOR. They would have produced a report listing why they feel there is a risk by not having User Groups implemented. If you feel that the risk is mitigated by other measures then let them know. It works best as a 2 way process and both parties can learn something.
SAP Query: Assignment to a User Group
If you want to extract your data from an InfoSet, the InfoSet must be assigned to a user group before the DataSource can be generated. This is necessary as the extraction is processed from an InfoSet using a query that comprises all fields of the InfoSet. In turn, this query can only be generated when the InfoSet is assigned to a user group.
Releases up to 3.1I
In releases up to 3.1I, a screen appears in which you have to specify a user group as well as a query name. The user group must be specified using the value help. In other words, it must already have been created. You can get more information about creating user groups in the SAP Query documentation, in the section System Management ® Functions for Managing User Groups.
A separate query is required for an InfoSet each time it is used in a DataSource. For this reason, enter a query name that was previously not in the system.
The query is generated after you confirm your entries.
Releases from 4.0A
In releases as of 4.0A, the InfoSet for the extract structure of the new DataSource is automatically assigned to the pre-finished system user group. A query is automatically generated by the system.
Query Areas
Query areas were created to allow you to fulfill varying requirements with SAP Query.
A query area contains a set of query objects (queries, InfoSets, and user groups) that are discrete and consistent.
You can differentiate between two different query areas, the standard area and the global area. Both query areas provide you with a full range SAP Query functions.
· Standard area
In the standard query area, all query objects (queries, InfoSets, user groups) are created and managed specifically for each client. Query objects are not attached to the Workbench Organizer, this means that they cannot be created and transported according to standard correction and transport procedures. This is a big advantage for end users that want to develop queries (ad-hoc reports) in their own client that are not meant for use in the rest of the system. Query objects can still be transported, however the transport process requires manual preparation and is not automatically initiated (export and import takes place using Query transport tools). For further information, see Transporting Standard Area Objects.
· Global area
Query objects in the global area are cross-client, that is they are available throughout the whole system and in all clients. Query objects in the global area are connected to the Workbench Organizer. They can be created and transported using the normal correction and transport procedures.
Transport is initiated automatically and no manual preparation is required. The global query area is therefore well suited for centrally developing queries meant for use and distribution throughout the system. All query objects delivered by SAP (from Release 4.0) are located in the global query area.
Both the global and the standard query areas contain discrete and consistent numbers of query objects. No relationships of any sort can exist between objects from different query areas. For example, you cannot create a query in the standard area using an InfoSet from the global area.
Each query area can be viewed as a discrete namespace for query objects. This means that objects can exist in different query areas that have the same name but different meanings.
Global Area Naming ConventionsHow to name queries, user groups, and InfoSets has already been discussed in the previous sections. When naming global area query objects, certain prefixes can be used.
You may only use a particular prefix after first having purchased its corresponding license.
A prefix is composed of '/prefix/' and precedes the actual object name. The / symbols before and after the prefix name are actually part of the prefix. A prefix can contain up to 10 characters including the two / symbols.
Pay attention to the following guidelines:
· InfoSet names can take the form '/prefix/InfoSet'.
The entire name of the InfoSet including prefix can contain up to 24 characters.
· User group names can take the form '/prefix/user_group'.
The entire name of the user group including prefix can contain up to 12 characters.
· Query names take the form 'query'.
Query names have no prefix of their own, instead they take the prefix of their user group. A query name can contain up to 14 characters.
· Prefixes may only be used with InfoSets and user groups from the global area. The Workbench Organizer checks to see if prefixes are used correctly.
The individual query object maintenance transactions check the name syntax described above. You can only work using name prefixes with query objects in the global query area. This is significant because it is in this area that query objects from SAP are inserted at PUT if necessary. All query objects delivered by SAP have the prefix '/SAPQUERY/', which has been reserved for them.
When using prefixes in the global area, ensure that objects whose names begin with a prefix belong to the development class with the same prefix. The Workbench Organizer checks to see if this condition has been fulfilled.
When creating queries for a user group whose prefix belongs to SAP, a business partner or another SAP customer, you must pay special attention to the fact that queries ‘inherit’ their prefixes from their user groups. These kinds of user groups can in turn be transported into your system using a PUT or other transport method. These queries then belong to the objects found in the namespace determined by the user group’s prefix.
If, for example, a query is created in the user group '/SAPQUERY/xx', then this query inherits the prefix '/SAPQUERY/'. It seems, therefore, that the query belongs to those objects delivered by SAP. This in turn could lead to the query being overwritten during the next transport. Therefore, it is recommended that no new queries be created in these user groups and that you use your own user groups when creating new queries.
Changing Query Areas
You can change query areas from each query object maintenance component by choosing Environment ® Query Areas. A window appears containing both query areas and their long texts.
Use Choose to choose the query area that you want. If you choose to work in the global area, this is displayed on the initial screen of the maintenance component. In the standard area no such text is displayed. The same maintenance component functions are available in both query areas.
You can display technical information about a query area by choosing Information on the screen where you chose which query area you wanted to work in. A dialog box appears where a long text is displayed along with information about whether or not the objects are client specific or linked to the Workbench Organizer.
Assigning Development Classes in the Global Area
Due to the fact that query areas are linked to the Workbench Organizer, a development class must be designated when query objects are created. Query objects are entered into a correction request whenever they are created or changed.
In the global area, you can classify query objects as local objects (using a temporary development class, usually $TMP). (This is the same as creating a query object in the standard area). There are several conditions that you should pay attention to when designating or changing development classes:
· All query objects in the global area have to be assigned to a development class (temporary development classes included). If the development class is not temporary, that is to say transportable, then the object must be entered in a correction request when it is being created or changed.
· User groups and InfoSets can be assigned to any development class you want.
· Queries can only be assigned to non-temporary development classes if their corresponding user groups and InfoSets are also assigned to non-temporary development classes. If, when you are creating a query, it is determined that either the InfoSet or user group assigned to that query is part of a temporary development class, then your query will automatically be assigned to development class $TMP. Whenever this happens, no dialog box asking you to determine a development class will appear.
In order to simplify matters, it is recommended that you always assign user groups and InfoSets in the global area to transportable development classes. In this way, all queries can be assigned to any development class you want.
All query objects in the global area that are assigned to non-temporary development classes must be entered in a correction request when being created or changed. An exception occurs with customizing settings. Changes like assigning users to user groups and InfoSets to user groups can be made without having to be entered in a correction request. Transports made using the Workbench Organizer do include InfoSets’ user group assignments, not however users’ user group assignments.
You can change development classes in the various query object maintenance components by choosing either Query ® More Functions ® Change Development Class, InfoSet ® More Functions ® Change Development Class or User Group ® Change Development Class. However, in accordance with the rules for assigning development classes formulated above, the following restrictions apply:
· Changing a user group from a non-temporary development class to a temporary development class only makes sense if all of the user group’s queries are assigned to a temporary development class.
· Changing an InfoSet from a non-temporary development class to a temporary development class only makes sense if all of the InfoSet’s queries are assigned to a temporary development class.
· Changing queries from a temporary development class to a transportable development class only makes sense if the InfoSet areas and user groups they are assigned to are in a transportable development class themselves.
The function Change development class... checks to see if you are allowed to change an object’s development class and displays a warning if this is not possible. You may then change the development class.
For technical reasons it is possible to make changes that conflict with the restrictions listed above. Therefore the system checks automatically to see if all changes made are acceptable. If a conflicting change has been made, a warning is displayed asking you to reconsider the change. If this were not the case, you would run the risk of having inconsistent datasets in all receiving systems after transport.
You can no longer change a development class when an object belongs to a transportable development class and has already been transported. This means that all development class changes described above must be made prior to transporting the object.
A development class change may also be necessary after a query object has been renamed. You must also ensure that the development classes of user groups and InfoSets that have been renamed still lie within the accepted name spaces for the new names. In this case it is advisable to choose an appropriate development class when you are renaming the object. With user groups the individual queries within the user group must also be assigned new development classes.
Renaming InfoSets and User Groups in the Global Area
When using the function Rename with InfoSets and user groups be aware of the fact that in addition to the InfoSet or user group, all dependent queries must also be renamed. If several InfoSets or user groups have been renamed, a series of queries must be included in a correction request in addition to the InfoSets and user groups. The renaming process is only actually finished when all objects necessary have been entered into a correction request.
Copying Query Objects between Different Query Areas
In order to copy query objects from one query area to another a special procedure must be followed to ensure that the datasets of each query area remain intact and consistent. During transfer you must check to see that the object being transferred can be inserted in the new dataset without upsetting the consistency of the latter. If you think of the global area as a single client, then the whole copying process, from the standard area to the global area and vice versa, corresponds to object transport from one client to the next. Thus, you copy query objects from one query area to the next in much the same manner as you copy objects within the standard area.
Only those users in possession of the necessary transport authorization (InfoSet and user group maintenance authorization) can copy query objects from one query area to another.
Global Area Query Variants
If you want to transport query variants within the global area, these variants must be created as system variants. System variant names begin with either SAP& or CUS&. Other kinds of variants cannot be transported. (Please see also the variant documentation available on the initial variant maintenance screen).