The Platform Search Analysis report queries the CMS for all related Platform Search info and gives the system administrator a snapshot of the current activity. It has built in alerts that will warn if certain settings are not configured to best practices. This analysis report is one that should be used by either the system administrator and/or SAP support personnel when troubleshooting a Platform Search related issue. Please make sure you have a clear understanding of the Platform Search workflow in BI4.x so you can take full advantage of the output. The following sections are included in the Platform Search Analysis Report:
Tab #1 - "PS Application Summary"
The first tab contains 2 sections: Application Summary and Application Status which are both described in more detail below.
This section contains information related to the 'Platform Search Application' infoobject. Most of the settings configured in the CMC ui (CMC home page > Applications page > Platform Search page) are stored in this section.
See the screenshot below for a better description on which property names point to which fields in the CMC.
This section represents the 'Platform Search Application Status' infoobject. There are a few properties here that can give you an idea of close the Platform Search index is to completion and which document was last indexed. The APS servers handle all the indexing for Platform Search. When the system starts indexing for the very first time, it will start with SI_ID = 0 and increment up until it reaches the most recent id. The property value (SI_PLATFORM_SEARCH_LAST_TO_BE_EXTRACTED_ID) in this section contains the last SI_ID that was loaded into the 'To Be Extracted Queue', which happens to be the first queue that Platform Search uses during its extraction/indexing workflow.
Consider the following example: Let's say the value of SI_PLATFORM_SEARCH_LAST_TO_BE_EXTRACTED_ID = 150142. This means that every SI_ID from 150142 and below have already been indexed (or is currently in the indexing process). All SI_ID's greater than this value have not been indexed yet which means those documents will not be returned in a search result from the BI Launchpad search bar.
Tab #2 - "APS Search Service Summary"
The second tab contains 2 sections: "APS Search Servers" and "APS Search Server Sessions" which are both described in more detail below.
APS Search Servers
This accordion lists each APS in the environment which contains a Platform Search service. If the server is in a running state, the server metrics will be displayed in the table. If the server is stopped, then the metrics are not retrievable from the CMS and thus it will only display the id, name, running status and disabled status. For those servers which are running, you'll be able to see more important data such as the Total Number of Documents Indexed, the Number of Documents Indexed Since Startup, Number of Failures and the Last Completed Index TimeStamp.
APS Search Server Sessions
This accordion displays the sessions created by a Platform Search service running on an APS. You should typically see one session for each running APS server (which contains a Platform Search service). Every time an APS server starts, it will open 1 new session in this list and there will be a period of time before the old sessions are dropped. If you witness old sessions hanging around, this can be due to a locked thread which is discussed in SAP NOTE 1719396. Focus on the HeartBeat TimeStamp value to determine if the session is in use.
Tab #3 - "PS Indexing Queues"
The last tab in the Platform Search Analysis Report is "PS Indexing Queues". In this tab, you'll find all of the information regarding the various queues used by the APS Platform Search service during the extraction and indexing workflow. Each accordion/ queue is labeled based on its infoobject name. Certain queues will only ever appear once, such as Queue 1, 3, 5 and 6. While Queues 2 and 4 each exist for every APS server. This means, if you have three APS servers with a Platform Search service, then you should also have three instances of Queue 2 and three instances of Queue 4. The last two queues displayed are "Exclude Documents" and "Include Documents". Each of these sections are described in more detail below.
Queue Summary displays a quick overview of the current status for Platform Search. You will see two graphs. The first shows how many documents exist in each queue. The 2nd graph shows total errors found in each queue. If a graph is displayed as empty, or if all values equal 0, this means there are no documents in any queue and no errors reported.
If Platform Search is currently running, then these values can potentially change every few minutes. Rerunning the report a few times, 5-10 minutes apart, can show progression of the index and can can help isolate if a single queue is becoming a bottleneck.
A document must work through queues 1-6 before it is considered 'indexed' and before it will appear in the BI Launchpad search results. Here's a high level description of the workflow:
- STEP 1: When its time for Document A to start the extraction process, it will first get inserted into Queue 1. Each valid infoobject is extracted based on SI_ID and each SI_ID is evaluated sequentially starting from SI_ID = 0. At this point, the infoobject Document A sits in Queue 1 'To-Be Extracted Queue' waiting to be assigned an APS.
- STEP 2: Once an APS takes on the job to start the extraction, the infoobject will be moved from queue 1 to queue 2. Each APS instance will have a corresponding Queue 2 as displayed in the report (Queue 2A, Queue 2B, etc).
- STEP 3: When it is finished with the extraction, the APS will move it into the next shared queue - Queue 3 'To Be Indexed Queue'. Here, it will wait again until another APS can take on the job of indexing.
- STEP 4: When an APS becomes available, the infoobject - Document A - will be moved from Queue 3 to Queue 4. Queue 4 is similar to Queue 2 in that each APS has its own dedicated queue.
- STEP 5: The document will reside in Queue 4 until it can be moved to Queue 5 and eventually Queue 6.
When looking at the details of the various queues within this report, focus on the queues which have documents contained within. You can easily see this from the chart displayed in the Queue Summary accordion. Once you drill into a certain queue (Queue 2A in the screenshots above), you'll be able to toggle on/off a 'More Details' button to show the details of the documents within the corresponding queue if any documents exist, otherwise the button will not be displayed.. If there is an error returned for one of these documents, you will see it here in the LAST ERROR MESSAGE property.
- No labels