1 / 28

SAP

jacob
Download Presentation

SAP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. SAP’s Data Dictionary Learning to use it effectively

    2. 11/13/2002 FSS Technical Peer Group Meeting 2 Introduction To know an application is to know its data Data dictionary holds key to performance Data dictionary tools reduce custom programming Becoming familiar with the major tables in a particular application is the first step to mastering that application area. For example, Accounts Receivable has 6 major tables, 2 master data tables (KNA1 & KNB1), 2 FI transactional tables (BKPF & BSEG), and 2 secondary FI/AR index tables (BSID - open or unpaid items & BSAD - cleared or paid items). Accounts Payable and General Ledger have the equivalent tables in their respective areas. Understanding the tables, their indexes, the relationship between tables and the data within the tables can make a dramatic difference in program performance. A combination of the data dictionary, extended table maintenance, table event user exits and view clusters can dramatically impact the resources and time needed for both development and long term maintenance for some simple custom relational tables.Becoming familiar with the major tables in a particular application is the first step to mastering that application area. For example, Accounts Receivable has 6 major tables, 2 master data tables (KNA1 & KNB1), 2 FI transactional tables (BKPF & BSEG), and 2 secondary FI/AR index tables (BSID - open or unpaid items & BSAD - cleared or paid items). Accounts Payable and General Ledger have the equivalent tables in their respective areas. Understanding the tables, their indexes, the relationship between tables and the data within the tables can make a dramatic difference in program performance. A combination of the data dictionary, extended table maintenance, table event user exits and view clusters can dramatically impact the resources and time needed for both development and long term maintenance for some simple custom relational tables.

    3. 11/13/2002 FSS Technical Peer Group Meeting 3 Agenda The SAP Data Model Data Filtration SAP Indexes Building Custom Tables/Simple Apps We’ll spend the first half of this presentation looking at SAP tables. We’ll explore the most common relationships found within SAP. We’ll talk about filtering out data that the program doesn’t need before the data is processed not afterwards. And we’ll talk about the kinds of indexes you’ll find in SAP and how programs should be structured to take the best advantage of these indexes. In the last half, I will demonstrate a simple application using some very powerful data dictionary tools that can greatly reduce development and maintenance costs.We’ll spend the first half of this presentation looking at SAP tables. We’ll explore the most common relationships found within SAP. We’ll talk about filtering out data that the program doesn’t need before the data is processed not afterwards. And we’ll talk about the kinds of indexes you’ll find in SAP and how programs should be structured to take the best advantage of these indexes. In the last half, I will demonstrate a simple application using some very powerful data dictionary tools that can greatly reduce development and maintenance costs.

    4. 11/13/2002 FSS Technical Peer Group Meeting 4 Vocabulary Relational Database Indexes Unique Index Primary Key Foreign Key (Check Table) One-to-Many Relationship Recursive Relationship Client Dependent View Cluster A relational database stores data in two or more tables and enables you to define relationships between the tables. Relationships are expressed in the data values of the primary and foreign keys. Indexes are used to retrieve data more quickly in the database. You can create more than one index for a table. A unique index is a column or columns in a table whose values uniquely identify each row in a table. Multiple unique keys can be defined for a table. Primary key is a unique index which defines the physical ordering of the data. It is *usually* the minimum set of fields sufficient to uniquely identity a row within a table, but not always. Within SAP, the Primary Key must be the the first contiguous fields in the table. A foreign key is a column or columns whose values are the same as the primary key of another table. In SAP the table a foreign key references is called the check table. A one-to-many relationship is one of the easiest relationships to visualize. A single MIT customer can have many transactions with us, such as library fines and dental bills. A MIT purchase order to one of our vendors can be for multiple items, such as file folders, staples, pads of legal paper, etc. A recursive relationship relates an entity to itself. For instance, a table of staff positions might include Directors, Managers, Programmers. On this table there is a field to indicate rank. There is only one highest ranked position and several lower ranked positions and even more lowest ranked positions. This is a one-to-many recursive relationship (i.e., a single table with relationships existing between rows within the table). How this is implemented will be explained later in the presentation. Client dependent describes all data stored in SAP tables which have the Client (MANDT) as the first of the primary key fields. Much of configuration, and all master & transactional data is client dependent. Workbench data, such as programs and table definitions is client independent. In the illustrations for this slide, MANDT is so ubiquitous that I leave it off the slides. When you create a table, MANDT must be the first key field. MANDT is left out of “select where clauses” unless “client specified” is included in statement. View Cluster is a tool supplied by SAP to rapidly create a screen for header and line item detail, often used by them for their configuration tables.A relational database stores data in two or more tables and enables you to define relationships between the tables. Relationships are expressed in the data values of the primary and foreign keys. Indexes are used to retrieve data more quickly in the database. You can create more than one index for a table. A unique index is a column or columns in a table whose values uniquely identify each row in a table. Multiple unique keys can be defined for a table. Primary key is a unique index which defines the physical ordering of the data. It is *usually* the minimum set of fields sufficient to uniquely identity a row within a table, but not always. Within SAP, the Primary Key must be the the first contiguous fields in the table. A foreign key is a column or columns whose values are the same as the primary key of another table. In SAP the table a foreign key references is called the check table. A one-to-many relationship is one of the easiest relationships to visualize. A single MIT customer can have many transactions with us, such as library fines and dental bills. A MIT purchase order to one of our vendors can be for multiple items, such as file folders, staples, pads of legal paper, etc. A recursive relationship relates an entity to itself. For instance, a table of staff positions might include Directors, Managers, Programmers. On this table there is a field to indicate rank. There is only one highest ranked position and several lower ranked positions and even more lowest ranked positions. This is a one-to-many recursive relationship (i.e., a single table with relationships existing between rows within the table). How this is implemented will be explained later in the presentation. Client dependent describes all data stored in SAP tables which have the Client (MANDT) as the first of the primary key fields. Much of configuration, and all master & transactional data is client dependent. Workbench data, such as programs and table definitions is client independent. In the illustrations for this slide, MANDT is so ubiquitous that I leave it off the slides. When you create a table, MANDT must be the first key field. MANDT is left out of “select where clauses” unless “client specified” is included in statement. View Cluster is a tool supplied by SAP to rapidly create a screen for header and line item detail, often used by them for their configuration tables.

    5. 11/13/2002 FSS Technical Peer Group Meeting 5 The Data Model The Data Model Master data Master data within company code One customer possibly doing business with multiple company codes (This model can continue into SD with one customer possibly doing business with multiple sales organizations.) Transactional data FI Header with a possibility of many line items (Example, a customer invoice debiting a receivable, which is essentially a promise from the customer to pay MIT, and crediting a revenue, which is essentially a department recognizing the income from a customer sale.) So How can we relate customers with their transactional data? Customer # is a field in BSEG but it is not a key field. The secondary index tables for AR/FI transactional data. (One FI line item can have a row in BSID, the AR open items and at the same time it can have a row in BSAD, the AR cleared or paid items. This happens when the customer has partially paid for the item.) This same model exists for General Ledger and Accounts Payable. Recursive Relationship within a single table Project Systems WBS Master Data A WBS Billing Element can have many unbillable children, grandchildren and great-grandchildren that roll their costs up to their billable parent. And finally our custom built tables can have relationships with each other. The Data Model Master data Master data within company code One customer possibly doing business with multiple company codes (This model can continue into SD with one customer possibly doing business with multiple sales organizations.) Transactional data FI Header with a possibility of many line items (Example, a customer invoice debiting a receivable, which is essentially a promise from the customer to pay MIT, and crediting a revenue, which is essentially a department recognizing the income from a customer sale.) So How can we relate customers with their transactional data? Customer # is a field in BSEG but it is not a key field. The secondary index tables for AR/FI transactional data. (One FI line item can have a row in BSID, the AR open items and at the same time it can have a row in BSAD, the AR cleared or paid items. This happens when the customer has partially paid for the item.) This same model exists for General Ledger and Accounts Payable. Recursive Relationship within a single table Project Systems WBS Master Data A WBS Billing Element can have many unbillable children, grandchildren and great-grandchildren that roll their costs up to their billable parent. And finally our custom built tables can have relationships with each other.

    6. 11/13/2002 FSS Technical Peer Group Meeting 6 The SAP Data Model Transactional Data One-to-Many One header row to many line items Master Data One-to-Many One master to many company code masters One master to many transaction line items Recursive data One parent to many children & grandchildren One purchase order, many line items within that purchase order. One customer in many company codes and one customer with many charges. One boss many subordinates. The “One” table or entity within a table should always be the driver in a program. In other words, find the “one” before gathering the “many” . It is far more efficient to gather information for the parent once per family than to gather it redundantly for each child. It is also easier to understand and maintain, as the code samples in subsequent slides will illustrate.One purchase order, many line items within that purchase order. One customer in many company codes and one customer with many charges. One boss many subordinates. The “One” table or entity within a table should always be the driver in a program. In other words, find the “one” before gathering the “many” . It is far more efficient to gather information for the parent once per family than to gather it redundantly for each child. It is also easier to understand and maintain, as the code samples in subsequent slides will illustrate.

    7. 11/13/2002 FSS Technical Peer Group Meeting 7 Report Example In most of your programs, it will be simple to visualize the “one”. It will either be master data, such as customer, or the transactional header, such as sales contract header. In this example, master data is not the “one” because this report was designed to handle a model that allowed multiple customers per sales contract. First build the header rows. Then for each header row, find the line items that belong to it. In most of your programs, it will be simple to visualize the “one”. It will either be master data, such as customer, or the transactional header, such as sales contract header. In this example, master data is not the “one” because this report was designed to handle a model that allowed multiple customers per sales contract. First build the header rows. Then for each header row, find the line items that belong to it.

    8. 11/13/2002 FSS Technical Peer Group Meeting 8 “One” Should be Driver In programs dealing with recursive relationships, it’s not so simple to visualize the “one” . The first set of code brings back all the WBS, parents, children, grandchildren, etc and loops through them all. For each of these WBS a parent is found. This means a single parent can be found many times. In the second set of code only the billable WBS are returned. Each billable WBS finds its children and grandchildren. This means a single child is found once and only once. How are these children found? In programs dealing with recursive relationships, it’s not so simple to visualize the “one” . The first set of code brings back all the WBS, parents, children, grandchildren, etc and loops through them all. For each of these WBS a parent is found. This means a single parent can be found many times. In the second set of code only the billable WBS are returned. Each billable WBS finds its children and grandchildren. This means a single child is found once and only once. How are these children found?

    9. 11/13/2002 FSS Technical Peer Group Meeting 9 Recursive Relationship The Recursive Relationship is the most difficult to conceptualize. Hence more slides. There is only one level 1 WBS (6900000). This level 1 WBS can have many children, grandchildren, great-grandchildren, etc (level 2, 3, 4, etc). Both of these (6900000 & 6900028) are billable WBS elements. These three (6000040, 6900030 & 6900029) will all roll up their expenses to their billable parent, 6900028. And all the other non-billable WBS (6900027, 6900039, 6900038, 6900037, 6900055, 690004) will roll up to the top (6900000). If relationships between tables are expressed in the data values of the primary and foreign keys, how are relationships expressed in recursive relationships? For maximum flexibility in the number of levels allowed, a relational “pointer” table must be created to resolve recursive relationships. The Recursive Relationship is the most difficult to conceptualize. Hence more slides. There is only one level 1 WBS (6900000). This level 1 WBS can have many children, grandchildren, great-grandchildren, etc (level 2, 3, 4, etc). Both of these (6900000 & 6900028) are billable WBS elements. These three (6000040, 6900030 & 6900029) will all roll up their expenses to their billable parent, 6900028. And all the other non-billable WBS (6900027, 6900039, 6900038, 6900037, 6900055, 690004) will roll up to the top (6900000). If relationships between tables are expressed in the data values of the primary and foreign keys, how are relationships expressed in recursive relationships? For maximum flexibility in the number of levels allowed, a relational “pointer” table must be created to resolve recursive relationships.

    10. 11/13/2002 FSS Technical Peer Group Meeting 10 PRHI - WBS Edges PRHI is such a pointer table for the WBS Elements. The subroutine “get_family” climbs down this table to gather together the children and grandchildren. By the way, the WBS elements that appear in the fields above are the external representation of an internal number. PRPS-PSPNR is the internal number, primary key. It can never change. PRPS-POSID is the external representation of this number. It can change. The fields above therefore, point to the unchangeable internal number. If you ran SE16 on PRHI, chances are you would see the internal numbers in the fields above, not the external number. You can change your SE16 settings to view the external representation of the internal number by: Settings -> User parameters Data Browser tab -> Format Check “Check conversion exits” in order to see the external number (POSID) Remove check “Check conversion exits” in order to see the real internal number (PSPNR).PRHI is such a pointer table for the WBS Elements. The subroutine “get_family” climbs down this table to gather together the children and grandchildren. By the way, the WBS elements that appear in the fields above are the external representation of an internal number. PRPS-PSPNR is the internal number, primary key. It can never change. PRPS-POSID is the external representation of this number. It can change. The fields above therefore, point to the unchangeable internal number. If you ran SE16 on PRHI, chances are you would see the internal numbers in the fields above, not the external number. You can change your SE16 settings to view the external representation of the internal number by: Settings -> User parameters Data Browser tab -> Format Check “Check conversion exits” in order to see the external number (POSID) Remove check “Check conversion exits” in order to see the real internal number (PSPNR).

    11. 11/13/2002 FSS Technical Peer Group Meeting 11 Filtering Data Billing Example The other common problem I find in programs that are not well designed is a lack of up front filtering. Many programs will process large amounts of data only to purge most of it prior to printing the report. The program above is a good example of such a poorly designed program. This filter is at the end of a long program that calculates cumulative expenses and revenue and current revenue for billable cost reimbursable WBS. Moving this filter to the beginning of the program improved performance twofold.The other common problem I find in programs that are not well designed is a lack of up front filtering. Many programs will process large amounts of data only to purge most of it prior to printing the report. The program above is a good example of such a poorly designed program. This filter is at the end of a long program that calculates cumulative expenses and revenue and current revenue for billable cost reimbursable WBS. Moving this filter to the beginning of the program improved performance twofold.

    12. 11/13/2002 FSS Technical Peer Group Meeting 12 Filtering Data MM Example KNOW YOUR DATA! In the original version of this program, all the POs went through lengthy processing. Filtering just those POs with open amounts and removing duplicate PO numbers from the initial select statement (distinct removes duplicates) reduced the runtime of this program from 6 hours to 1 hour!KNOW YOUR DATA! In the original version of this program, all the POs went through lengthy processing. Filtering just those POs with open amounts and removing duplicate PO numbers from the initial select statement (distinct removes duplicates) reduced the runtime of this program from 6 hours to 1 hour!

    13. 11/13/2002 FSS Technical Peer Group Meeting 13 SAP Indexes Primary Key Secondary Indexes Secondary Index Tables Foreign Key The Primary Key must include MANDT for all client dependent tables, which includes all master and transactional data and any custom table that will be maintained in production. All the fields that make up a Primary Key must be contiguous and must appear at the beginning of the table definition. The Primary Key must be unique. It is the physical key. In other words, the data is stored in Primary Key order. When you can use a Primary Key in a “select where clause”, do so. It is the most efficient of the indexes. There are times when we can not use the Primary Key. At those times, look for Secondary Indexes. If an appropriate Secondary Index does not exist look for a Secondary Index Table. If nothing exists and the query is one that is used frequently, then consider requesting that the BASIS team create a Secondary Index for the query. When none of these possibilities exist, do a non-index select once into an internal table and sort the internal table by the non-indexed field of interest. Then you can read the internal table using a binary search. The Foreign Key references the “One” table.The Primary Key must include MANDT for all client dependent tables, which includes all master and transactional data and any custom table that will be maintained in production. All the fields that make up a Primary Key must be contiguous and must appear at the beginning of the table definition. The Primary Key must be unique. It is the physical key. In other words, the data is stored in Primary Key order. When you can use a Primary Key in a “select where clause”, do so. It is the most efficient of the indexes. There are times when we can not use the Primary Key. At those times, look for Secondary Indexes. If an appropriate Secondary Index does not exist look for a Secondary Index Table. If nothing exists and the query is one that is used frequently, then consider requesting that the BASIS team create a Secondary Index for the query. When none of these possibilities exist, do a non-index select once into an internal table and sort the internal table by the non-indexed field of interest. Then you can read the internal table using a binary search. The Foreign Key references the “One” table.

    14. 11/13/2002 FSS Technical Peer Group Meeting 14 Secondary Index Table BSID (open items) and BSAD (cleared items) are examples of Secondary Index Tables for the line item table, BSEG, in FI. If you attempted to query BSEG on customer, it would be a very long search. BSEG is a “cluster table”, which is a SAP table type that does not allow Secondary Indexes. The existence of BSID and BSAD allows us to query FI line items via customer number. BSIS & BSAS are the general ledger secondary index tables and BSIK& BSAK are the accounts payable secondary index tables. The Primary Key for BSID are those fields marked under the column “Key.” You can view the Secondary Indexes by clicking on the “Indexes…” soft button. Notice that the Foreign Key, BUKRS, references the company code in the customer company code table, KNB1 not the enterprise wide company code table, T001. MANDT is always the first field in any index, including the Primary Key and Foreign Keys (select a Foreign Key and click on the “key” icon to see the fields involved in the Foreign Key). BSID (open items) and BSAD (cleared items) are examples of Secondary Index Tables for the line item table, BSEG, in FI. If you attempted to query BSEG on customer, it would be a very long search. BSEG is a “cluster table”, which is a SAP table type that does not allow Secondary Indexes. The existence of BSID and BSAD allows us to query FI line items via customer number. BSIS & BSAS are the general ledger secondary index tables and BSIK& BSAK are the accounts payable secondary index tables. The Primary Key for BSID are those fields marked under the column “Key.” You can view the Secondary Indexes by clicking on the “Indexes…” soft button. Notice that the Foreign Key, BUKRS, references the company code in the customer company code table, KNB1 not the enterprise wide company code table, T001. MANDT is always the first field in any index, including the Primary Key and Foreign Keys (select a Foreign Key and click on the “key” icon to see the fields involved in the Foreign Key).

    15. 11/13/2002 FSS Technical Peer Group Meeting 15 BSID’s Secondary Indexes The Primary Key is usually the minimum number of fields necessary to define uniqueness, although this is not always true. If it isn’t true, then a Unique Index, which does represent the minimum, is defined as a Secondary Index. The first Secondary Index for BSID is such a Unique Index. Notice that the following select would not use the Primary Key because the first field (outside of MANDT) in the Primary Key is not being used in the “select where clause”. But the unique Secondary Index will be used, because KUNNR is the first field in the Secondary Index. select ... from bsid where kunnr = t_kna1-kunnr and zuonr = c_allocation. The Primary Key is usually the minimum number of fields necessary to define uniqueness, although this is not always true. If it isn’t true, then a Unique Index, which does represent the minimum, is defined as a Secondary Index. The first Secondary Index for BSID is such a Unique Index. Notice that the following select would not use the Primary Key because the first field (outside of MANDT) in the Primary Key is not being used in the “select where clause”. But the unique Secondary Index will be used, because KUNNR is the first field in the Secondary Index. select ... from bsid where kunnr = t_kna1-kunnr and zuonr = c_allocation.

    16. 11/13/2002 FSS Technical Peer Group Meeting 16 Recursive Resolution Table Notice the foreign keys and check table on the relational pointer table, that resolves the recursive relationships within the WBS master table, PRPS.Notice the foreign keys and check table on the relational pointer table, that resolves the recursive relationships within the WBS master table, PRPS.

    17. 11/13/2002 FSS Technical Peer Group Meeting 17 BKPF Primary & Foreign Keys The keys viewed from SE16 The Primary Key - notice the slight variation in color. Client and Company Code are both part of the Primary key and are Foreign Keys. The Foreign Key Plain table fields Note that the Secondary Indexes are not distinguished from non-indexed table fields.The keys viewed from SE16 The Primary Key - notice the slight variation in color. Client and Company Code are both part of the Primary key and are Foreign Keys. The Foreign Key Plain table fields Note that the Secondary Indexes are not distinguished from non-indexed table fields.

    18. 11/13/2002 FSS Technical Peer Group Meeting 18 COVP Useful Secondary Index COVP is a view that joins the CO header table, COBK, and the CO line item table, COEP. COEP holds all expense and revenue line items. It does not hold balance sheet line items, such as the customer receivable or the vendor liability. BSEG holds both, but does not have any secondary indexes. BSID & BSAD hold the balance sheet receivable transactions but not the revenue transactions. (The equivalent is true for the 2nd index tables for AP and GL.) So COVP is a very useful view, because it has excellent secondary indexes. I know that I just used a lot of accounting jargon that most technical staff do not understand and do not want to understand. But SAP FI is a business accounting package. To understand it, you must understand standard accounting. There is a small book, A Review of Essentials of Accounting, that I own and am willing to loan out. (There are times you will need to use constants to query meaningless (for MIT) higher order index fields in order to use an index. LEDNR (ledger) and VERSN (version) are examples of such constants.) The above query will return the revenue for a TLO WBS License Agreement (4579002) posted in fiscal year 2003. I found the object number for this WBS, PR00019679, by querying PRPS. 801051 is the CO revenue cost element for Licensing Fees.COVP is a view that joins the CO header table, COBK, and the CO line item table, COEP. COEP holds all expense and revenue line items. It does not hold balance sheet line items, such as the customer receivable or the vendor liability. BSEG holds both, but does not have any secondary indexes. BSID & BSAD hold the balance sheet receivable transactions but not the revenue transactions. (The equivalent is true for the 2nd index tables for AP and GL.) So COVP is a very useful view, because it has excellent secondary indexes. I know that I just used a lot of accounting jargon that most technical staff do not understand and do not want to understand. But SAP FI is a business accounting package. To understand it, you must understand standard accounting. There is a small book, A Review of Essentials of Accounting, that I own and am willing to loan out. (There are times you will need to use constants to query meaningless (for MIT) higher order index fields in order to use an index. LEDNR (ledger) and VERSN (version) are examples of such constants.) The above query will return the revenue for a TLO WBS License Agreement (4579002) posted in fiscal year 2003. I found the object number for this WBS, PR00019679, by querying PRPS. 801051 is the CO revenue cost element for Licensing Fees.

    19. 11/13/2002 FSS Technical Peer Group Meeting 19 COVP Primary & Foreign Keys The results from this very fast query: Again notice the color variation in the Primary key. The lighter blue is the foreign key within COEP that points to its parent in COBK. The Foreign Keys Plain table fields Note that the Secondary Index we used for this selection (LEDNR, OBJNR, GJAHR, WRTTP, VERSN, KSTAR - ledger, cost object, fiscal year, value type - actual versus budget, version, cost element) is not color coded above.The results from this very fast query: Again notice the color variation in the Primary key. The lighter blue is the foreign key within COEP that points to its parent in COBK. The Foreign Keys Plain table fields Note that the Secondary Index we used for this selection (LEDNR, OBJNR, GJAHR, WRTTP, VERSN, KSTAR - ledger, cost object, fiscal year, value type - actual versus budget, version, cost element) is not color coded above.

    20. 11/13/2002 FSS Technical Peer Group Meeting 20 Additional Useful Indexes Remember URLs are case sensitive.Remember URLs are case sensitive.

    21. 11/13/2002 FSS Technical Peer Group Meeting 21 Building Custom Tables Create Header Table Create Line Item Table Create Maintainable Views for Header & Items SE54 - Extended Table Maintenance for Views Program & Activate Event User Exits Data validations SE54 - Create View Cluster SM34 - Maintain View Cluster SF8 View Cluster name is ZSDBLINE_VC Finally we’ve gotten to the fun part of the presentation, creating custom relational tables, with maintenance views that include data validation without having to create and maintain all the dialog programming that usually goes along with custom applications! Unfortunately, I spent so much time researching and creating the first half of this presentation, I had very little time to devote to this second half. So bare with me as I wing it. I did the underlying work on these tables a couple of months ago for the Lincoln project and did not have time to carefully document each key stroke as I fumbled my way through this new arena. Therefore, this presentation is a road map but not a step by step recipe. I would like to thank John Hosken for introducing this powerful tool to the MIT and Lincoln Lab programmers at one of David Rosenberg’s lunch time seminars.Finally we’ve gotten to the fun part of the presentation, creating custom relational tables, with maintenance views that include data validation without having to create and maintain all the dialog programming that usually goes along with custom applications! Unfortunately, I spent so much time researching and creating the first half of this presentation, I had very little time to devote to this second half. So bare with me as I wing it. I did the underlying work on these tables a couple of months ago for the Lincoln project and did not have time to carefully document each key stroke as I fumbled my way through this new arena. Therefore, this presentation is a road map but not a step by step recipe. I would like to thank John Hosken for introducing this powerful tool to the MIT and Lincoln Lab programmers at one of David Rosenberg’s lunch time seminars.

    22. 11/13/2002 FSS Technical Peer Group Meeting 22 Create Header Table SE11 Database Table - Create There must be no breaks in the Primary Key and it must appear at the beginning of the table with Client as the first field. In this example duplicate prime_contracts will not be allowed. Creating custom field types allowed me to associate custom search help and custom documentation with the fields. Actually, I only needed the custom field types for the custom documentation. Search help could have been assigned to the fields by double clicking the field name and then clicking on the soft button, “Search Help for Field.” See http://fuller.mit.edu/tech/Search Helps.ppt for the search help hierarchy used by SAP.SE11 Database Table - Create There must be no breaks in the Primary Key and it must appear at the beginning of the table with Client as the first field. In this example duplicate prime_contracts will not be allowed. Creating custom field types allowed me to associate custom search help and custom documentation with the fields. Actually, I only needed the custom field types for the custom documentation. Search help could have been assigned to the fields by double clicking the field name and then clicking on the soft button, “Search Help for Field.” See http://fuller.mit.edu/tech/Search Helps.ppt for the search help hierarchy used by SAP.

    23. 11/13/2002 FSS Technical Peer Group Meeting 23 Custom Search Help SE11 Data type & Search help Or double click on field name and then click the soft button, “Search Help for Field.” SE11 Data type & Search help Or double click on field name and then click the soft button, “Search Help for Field.”

    24. 11/13/2002 FSS Technical Peer Group Meeting 24 Custom Field Documentation SE11 Data typeSE11 Data type

    25. 11/13/2002 FSS Technical Peer Group Meeting 25 Create Line Item Table SE11 Database Table - Create Foreign key and check table are defined by selecting the field and clicking on the “key” icon next to “New rows” button.SE11 Database Table - Create Foreign key and check table are defined by selecting the field and clicking on the “key” icon next to “New rows” button.

    26. 11/13/2002 FSS Technical Peer Group Meeting 26 Create Maintainable View SE11 View - Create Maintenance view is NOT the default. Make sure you select this view type! After entering the short text description for this view, enter the line item table as the first table under “Tables”. Then click the button “Relationships” which is at the bottom of this column (not shown on this slide) All the “check tables” that appear in ZSDBLINE will be presented. Choose the header table. The Header table will be added to the list of “Tables” and the “Join conditions” will be defaulted in as they appear above. I also created a maintainable view for the header table. The only table involved with that view was the header table. SE11 View - Create Maintenance view is NOT the default. Make sure you select this view type! After entering the short text description for this view, enter the line item table as the first table under “Tables”. Then click the button “Relationships” which is at the bottom of this column (not shown on this slide) All the “check tables” that appear in ZSDBLINE will be presented. Choose the header table. The Header table will be added to the list of “Tables” and the “Join conditions” will be defaulted in as they appear above. I also created a maintainable view for the header table. The only table involved with that view was the header table.

    27. 11/13/2002 FSS Technical Peer Group Meeting 27 View Fields These are the view fields with the possible values for the maintenance attribute. H will be hidden and populated via a user exit S are the header fields that appear in read-only format above the line items in the view cluster.These are the view fields with the possible values for the maintenance attribute. H will be hidden and populated via a user exit S are the header fields that appear in read-only format above the line items in the view cluster.

    28. Extended Table Maintenance SE54 - Generated Objects SE54 Generated Objects - Create Be sure to give it an authorization group. There should be two authorization groups associated with custom tables in a particular application area. One authorization group will be for “read-only” access and the other for “maintenance”. Make sure to use the one for “maintenance.” The function group should be the function group that the table was created under. It will be the function group where the user exit validations will appear. I also generated a table maintenance object for the header view I created. SE54 Generated Objects - Create Be sure to give it an authorization group. There should be two authorization groups associated with custom tables in a particular application area. One authorization group will be for “read-only” access and the other for “maintenance”. Make sure to use the one for “maintenance.” The function group should be the function group that the table was created under. It will be the function group where the user exit validations will appear. I also generated a table maintenance object for the header view I created.

    29. 11/13/2002 FSS Technical Peer Group Meeting 29 Create an Include via SE38 SE38 Create an include All the validation subroutines for your view should be in this include. I also created an include for validations of the header view.SE38 Create an include All the validation subroutines for your view should be in this include. I also created an include for validations of the header view.

    30. 11/13/2002 FSS Technical Peer Group Meeting 30 Modify Function Pool Modify the function pool in which you created your views and their extended table maintenance screens by removing the comment from the user-defined include files of interest. Double click the include you just uncommented and it will ask you if you wish to create it. Say yes.Modify the function pool in which you created your views and their extended table maintenance screens by removing the comment from the user-defined include files of interest. Double click the include you just uncommented and it will ask you if you wish to create it. Say yes.

    31. 11/13/2002 FSS Technical Peer Group Meeting 31 Modify Lfunction_groupFXX Add the includes you created to the SAP generated include, which you just uncommented in the slide before.Add the includes you created to the SAP generated include, which you just uncommented in the slide before.

    32. Events SE54 -> Environment -> Events CHECK_TOTAL and VALIDATE_ZSDBLINE_V are two subroutines in the Include program, shown in the last slides. Event codes I used were “After saving the data in the database” and “Creating a new entry” I also created an event for the header view. It was an 05 event code.CHECK_TOTAL and VALIDATE_ZSDBLINE_V are two subroutines in the Include program, shown in the last slides. Event codes I used were “After saving the data in the database” and “Creating a new entry” I also created an event for the header view. It was an 05 event code.

    33. Create View Cluster SE54 -> Edit viewcluster Enter the name you want for your view cluster and click on “Create/change”Enter the name you want for your view cluster and click on “Create/change”

    34. 11/13/2002 FSS Technical Peer Group Meeting 34 Object structure I created this view cluster via trial and error. I had nothing to reference. It works, which is about all I can say!I created this view cluster via trial and error. I had nothing to reference. It works, which is about all I can say!

    35. 11/13/2002 FSS Technical Peer Group Meeting 35 Generated Field Dependences This was automatically generated when I clicked on the “Field-dependence” generate button from the previous screen.This was automatically generated when I clicked on the “Field-dependence” generate button from the previous screen.

    36. 11/13/2002 FSS Technical Peer Group Meeting 36 Generated Field Dependences Again this was automatically generated by selecting the line item object structure and clicking the “Field-dependence” button.Again this was automatically generated by selecting the line item object structure and clicking the “Field-dependence” button.

    37. 11/13/2002 FSS Technical Peer Group Meeting 37 View Cluster - Line Items SM34 A quick demo of the results.A quick demo of the results.

    38. 11/13/2002 FSS Technical Peer Group Meeting 38 Summary Know your program “driver” Find the “One” in the application data model Filter the data early in the program Know the indexes available in an area If you can’t use the primary index there are usually other indexes Use the SAP supplied tools when possible

    39. 11/13/2002 FSS Technical Peer Group Meeting 39 Where to Get More Information BC430 ABAP Dictionary Tomorrow in Waltham (11/14 - 11/15) January 9 - 10, 2003 Waltham My personal favorite, the book Object-Oriented Systems Analysis - Modeling the World of Data by Sally Shlaer & Stephen Mello Available, used on www.amazon.com

More Related