Reduced downtime for Initial Indexing in Solution Documentation - Indexing by Branch

[shansari]

There are scenarios when complete re-indexing or even recreation of search connectors followed by initial indexing is required in SAP Solution Manager Solution Documentation for search infrastructure to function. For example:

• After a Support Pack Upgrade


• When a connector is corrupt and requires recreation

In such scenarios, if the number of documents and elements have grown substantially high in each branch and there are multiple branches, the search infrastructure can have a downtime of several days. To mitigate the risk with long downtimes of complete solution documentation search, there exists a pilot concept of 'Indexing by Branch'.

What is Indexing by Branch?

When performing complete indexing of SMUD* search connectors, indexing by branch provides you the possibility of prioritising the branches in an order in which they should be indexed and be available again in the same order. As a result, the search infrastucture for solution documentation is not unavailable for the whole period all branches are being indexed. Branches are indexed sequentially prioritywise. The search infrastructure for the branches indexed first is available first for all functions.

When to use Indexing By Branch?

When the number of documents and elements in solution documentation are so high with several branches that initial indexing of a SMUD Search connector can last for more than a weekend.

When the branch concept is so defined that the priority of some branches being available for usage is sufficient or much higher than other branches.

How can we implement Indexing by Branch?

Considering it is a pilot concept, an incident has to be opened for SAP to include your customer number for the pilot implementation. Please read through the details, constraints and process as explained in notes 2717130

Primarily, there are two approaches based on whether in your respective productive Solution Manager system, the client is open for table maintenance.

The note 2717130 has word documents with screenshots for both the approches listed below for reference and clarity.

• Option1: Using table BRANCH_SEQUENCE when table maintenance in Production is NOT possible

Here is an overview of steps:

1. Maintain the table BRANCH_SEQUENCE via transaction SM30 in the Dev System, numbering the rounds starting with 1 and proceeding with 2, 3 etc. Please make sure to use the input help to select the entries since the name of the branch as it appears and technical name could be different.


2. Transport the table entries into the production system.


3. Use report RSMUD_SEARCH_BRANCH_INDEXING to initialize status, changed_at and changed_by


4. Repeat initial scheduling until all branches in the table are indexed. Note to use "Clear Index Content" only for the FIRST round and "Keep Index Content" for all other rounds. Use report RSMUD_SEARCH_BRANCH_INDEXING to update the status with success or error after each round.


5. Use report RSMUD_SEARCH_BRANCH_INDEXING to update the status for each Round.


6. In case you have to update with error, check ESH_COCKPIT for details and if you are unable to fix the error, open an incident before proceeding further.


7. After all listed branches in BRANCH_SEQUENCE are indexed and the status is updated, perform a last run for all branches which are not contained in BRANCH_SEQUENCE.


8. The use the report RSMUD_SEARCH_BRANCH_INDEXING to reset the status values.

• Option2 : Using table BRANCH_WHITE when table maintenance in Production is possible

Here is an overview of steps:

1. Deletion of the search object connectors (SMUD_ELEMENT and SMUDKW_INFO_OBJECT)
   - transaction ESH_COCKPIT


2. Creation of the search model
   - transaction SOLMAN_SETUP - Process Management - Step 6 Configure Embedded Search - Manual activity: Create Search Models. This starts report RSMUD_SEARCH_MODEL_CREATE


3. Creation of the search connectors
   - transaction SOLMAN_SETUP - Process Management - Step 6 Configure Embedded Search - Manual activity: Create Search Connectors
   (identical to ESH_COCKPIT - button "Create")


4. Design the sequence of branches (use any documentation of your own)


5. Maintainance of branch(es) for round 1
   - transaction SM30 for view V_BRANCH_WHITE_L


6.  Indexing of branch(es) for round 1
   - transaction ESH_COCKPIT, press button „Actions“ and select „Schedule Indexing“  (mode: "Clear index content" - is faster than "keep ...") NOTE: after round 1, the connector status of SMUD_ELEMENT and SMUDKW_INFO_OBJECT will switch to "active".
   You are now able to search the content which is indexed (= the content of the branch(es) of the first round) without having to wait for the completion of the indexing of the other branches below. Keep in mind that you will not yet find the hits which would be indexed in the remaining steps starting with step 7 until all remaining steps are executed.


7. Maintenance and indexing of branch(es) for rounds 2 to (n-1)
   - transaction ESH_COCKPIT, press button „Actions“ and select „Schedule Indexing“
   (ATTENTION: indexing mode: "Keep index content" (not "clear")- otherwise index content of first branch from steps 5+6 is deleted !!!)


8. Maintenance and indexing of remaining branch(es) for round n (if any remain)
   - transaction ESH_COCKPIT, press button „Actions“ and select „Schedule Indexing“
   (indexing mode: keep index content)

Observations & Experiences with Indexing by Branch:

• It really depends on your respective system and use case if the concept can add value. Please read through section 'When to use Indexing by Branch' above.


• The overall runtime of intial indexing of all branches together as a sum could end up being higher. The advantage is if we need only maintenance & production branch to be available for business, to use these branches one does not have to wait for the rest of the branches to be indexed.


• Increased manual effort. Since the trigger for each branch has to be executed separately, the system administrator would need to monitor for completion of indexing of preceding branch and trigger indexing for next branch.

We worked with table BRANCH_SEQUENCE and this ensured that our business critical branches are always available within allowed downtime timeframe.

Let me know in the comments if you also face challenges with growing solution documentation content and initial indexing, also if you came across other solutions that could help optimise the process.

For more solution documentation related blogs, follow this page: SOLMAN Process Management