Accelerate PLM classification search especially for DMS

The classification system (CA-CL) is a powerful tool inside SAP PLM. It allows adding business specific attributes to objects and grouping and structuring them. Main purpose is to enable users to find more easily their content later. However searching for classification can be quite slow when the content grows. One application that heavily uses classification is the document management system (CA-DMS). I know customers that have more than a million documents and don’t want to spend too much time waiting for a search result. This blog is about a feature of the classification system that allows you to speed up your search by up to 90%, and we are talking about minutes in some cases!

Why is searching for classification slow? Simplified the classification is nothing more than a name and value pair stored in one table that has a lot of rows. State of the art data bases are still optimized to find content in columns and not in rows. So the main concept of accelerating classification search is to store the content in additional tables in column form and put an index over it; that is why it is called Generated index tables. This feature is already available since R/3 4.6 (1999). By the way, the SAP’s BI Accelerator is based on same idea. In general search leveraged by an index server is state of the art technology. PLM 7.0 offers search functionality that is completely build on an index server, including structured and non structured data. This technology is called Embedded Search and it currently supports a lot of objects except classification. This will hopefully change with PLM 7.1.

But let us come back to pur topic. Technically the classification system is more than a name and value pair as it offers the following features:

• Internal and extern language depended values
• Support of change management, to store revision security and keep all data along the time axis
• Characteristics with multiple values
• Case sensitive values
• Numeric values
• Values with a unit of measure (conversion necessary when searching)
• Intervals

So you see it is more a pimped up name and value pair that makes searching quite complicated. However the “Generated index tables” can handle all the features with a top response time. Let us have a look how to set up: We look at an example from the DMS, because there the classification is well integrated.

1. Customizing

Enter the Classification customizing in IMG with the following path.
Cross-Application Components -> Classification System -> Classes -> Maintain Object Types and Class Types

Basically two settings have to be enabled for the specific class type:

1. Multiple classification
2. Generated tables

Now the second checkbox can be flagged easily, if the first one is flagged. The fist flag can only be changed in the customizing if no classification exists on the database. Otherwise you have to migrate the existing data with the report RCCLUKA2.

Background: The feature “Multiple classification” carries the wrong name; it should be called “Enable progressive features”. Since the classification system exists before release 4.6C the developers came to a point where they had to release from old burdens and that is why they introduced a migration path. Technically a new DB key is introduced and the old is stored in the DB table INOB. For more information have a look at note 942691.

Just a few remarks:

• This is a migration: make sure you test it in your quality assurance system. You might want to execute this report in the background to avoid a dialog timeout.
• Close the customizing transaction before executing the report, because it will set the flag automatically.
• Run this report before you import the “Maintain Object Types and Class Types” customizing from transportation.
• If you have custom programming in your system retest you business logic. Some underpaid consultants might have hard-coded the limitation not to use the new feature.

Whenever you manage to set the two features, let’s continue.

2. Set up your classes

Nothing is endless, so the developers had to limit the number of index characters. I don’t know why but the limitation is 12 characteristics for every class. If you have more characteristics, focus on the 12 most important ones. If a user searches for a characteristic not covered by the twelve, still the old slow search logic will give a search reult.
The flag for the 12 characteristics is hiding in the last column “Index relevant” in the transaction CL02 “Classes”.

3. Generate the Index Tables

Now are you ready to press just one button to do the whole optimization and generate the index tables: Call transaction CLGT – “Set Up Tables for Search”, enter your class and hit execute.

Two remarks:

• You have to run the transaction for every class
• You might want to run the generation in the background.

Result

You are finished now. Go to transaction CL30N – “Find Objects in Classes” and perform a search. The result should show up much faster!
The new index tables are also filled automatically with new or changed values.

Optional: Speed up document search

If you use the DMS you will properly go to transaction CV04N – “Document Search” and find out, that nothing has changed. Don’t worry: I am not finished yet!
CV04N is a complex search transaction, which has to handle different sources. For this a search strategy is developed and classification is not asked first. So a result list is already passed to the classification search function and this is not supported with the index search. All you have to do is make classification search the first, if a user wants to search for classification. This can be done within a BAdI implementation of DOCUMENT_SEARCH01. This BAdI is available since ERP 6.0 (2005). Note 993462
The following code will make classification the first in the search order
METHOD if_ex_document_search01~change_search_order.  DATA:  ls_order_classif      TYPE cv100_ts_search_order,  ls_order              TYPE cv100_ts_search_order,  lt_search_order_old   TYPE dms_tbl_search_order  .* when a user searches for classification, it it necessary to change the sort order,* because index classfication search only works,* if no first results are passed to CLSC_SEARCH_OBJECTS* user must want to search for classification.  IF clsc_class_selection IS NOT INITIAL  OR class_selection IS NOT INITIAL.    READ TABLE search_order INTO ls_order_classif WITH KEY search_number = ’05’.    IF sy-subrc <> 0.      RETURN.    ENDIF.    lt_search_order_old = search_order.    CLEAR search_order.    INSERT ls_order_classif INTO TABLE search_order.    LOOP AT lt_search_order_old INTO ls_order.      IF ls_order <> ls_order_classif.        INSERT ls_order INTO TABLE search_order.      ENDIF.    ENDLOOP.  ENDIF.ENDMETHOD.
The implementation above can also help to speed up of CV04N search in ERP 6.0 if no index tables exist, because in most cases the classification search is much faster, if it does not have to handle a result list. Check out an article in the Wiki. However if it comes to complicated requests (case sensitive words or intervals) only a index search can really accelerate.

Result 2.0

Now the performance of CV04N should also have improved. The search is also accelerated in Easy DM, since it uses the same logic.

Restrictions

A few restrictions exit:

• If you use a class hierarchy with inherited characteristics you have to add these inherited ones also to the sub-class in order to benefit also from the speed up
• You can select up to 12 characteristics per table for finding objects. (mentioned already)
• You can select reference characteristics, but have to enable “Redundant storage” in the customizing
• The engineering change management is supported, however only with date validity and not parameter validity.
• Table generation cannot be used for variant class types (class type 300).
• If the “Without values” indicator is set in the user settings, table generation does not improve system performance.

Technical Details

It is quite amazing what the generation program all does:

• It generated a table for all singe values of a class. (name is stored in DB table GEN_TABLES_MAIN)
• It generates for every multiple value characteristic a own table (name is stored in DB table GEN_TABLES_SUB)
• Every characteristic gets their optimized Data Dictionary type
• For case sensitive values a big letter column is created in addition.
• For intervals a low and high column is created
• A view is generated to unit all tables
• All tables carry the correct index.

Conclusion

It is quite amazing what can be done with a tool that is 10 years old and hardly know. I hope you could manage to accelerate you search.