MicroStrategy ONE
Action Hierarchy
Every Intelligence server and Identity server log is processed and stored at the transactional (Action, Parent Action) level in the main fact table access_transaction.
The action hierarchy allows users to analyze the type of actions that a user is performing on the system. A sample of transaction types (i.e. Action Types) includes: logging into a project, executing a report, republishing a cube, creating a history list message or scanning a Badge QR Code. The full lists of Action Types are included in the following section.
The Action Category is a grouping of Action Types. It provides a broader analysis of user actions i.e. Executions or Badge Actions.
Each Action has a corresponding Status and Status Category. The Status and Status Category are used to differentiate successful or failed transactions.
These are the facts sourced from the access_transaction table:
- Action - The Action fact records the unique tran_id recorded in the access_transaction table
- Action Start Timestamp (UTC) - UTC Timestamp of when the Action (execution) began.
- Action Finish Timestamp (UTC) - UTC Timestamp of when the Action (execution) finished.
- Execution Duration (ms) - The Execution Duration (ms) fact records the total time spent during an action (execution) in milliseconds.
- Prompt Answer Duration (ms) - The Prompt Answer Duration (ms) fact records the total time spent answering a prompt during an action (execution) in milliseconds.
- Total Queue Duration (ms) - The Total Queue Duration (ms) fact records the total time spent waiting in queue for the job to be executed in milliseconds. This includes initial queue time and the queue time between different steps.
- Row Count - The number of rows in the result set.
- Step Count - The number of steps completed during an execution.
- SQL Pass Count - The number of SQL passes required to generate the result set for the execution.
- CPU Duration - The time spent on CPU during job execution in milliseconds.
- Initial Queue Duration (ms) - Total time spent by the job waiting in initial queue to begin execution in milliseconds.
- Job Step total Queue Duration (ms) - Time spent waiting in the queue between job steps in milliseconds.
- Elapsed Duration (ms) - Total time spent executing a job from queue to finish in milliseconds.
- Total Processing Duration (ms) - Total time spent executing a job from queue, through waiting for prompt answers, to finish in milliseconds.
- Job Start Timestamp (UTC) - The timestamp (in UTC timezone) a job began execution.
access_transaction
|
Column |
Description |
Data-Type |
|---|---|---|
|
tran_id |
Auto-generated numeric action ID. This is the source column for the Action attribute and the Action fact. Action is the lowest level that is defined in the Platform Analytics project schema. |
bigint(20) |
|
parent_tran_id |
Auto-generated numeric Parent Action ID. This is the source column of the Parent Action attribute. Parent Action is one level above Action and was introduced to account for the "Bucketing" of multiple transactions within a single session/job. |
bigint(20) |
|
account_id |
The account ID of the account who performed the transaction. The Account can be either Badge or MicroStrategy metadata users. See lu_account for more details. |
bigint(20) |
|
tran_lat |
The longitude point where the transaction occurred. Location analysis is specific to Badge transactions. This is the source column for the Latitude attribute. |
double |
|
tran_long |
The latitude point where the transaction occurred. Location analysis is specific to Badge transactions. This is the source column for the Longitude attribute. |
double |
|
tran_timestamp |
The standardize UTC timestamp when the transaction began. This is the source column for the ID form of the Timestamp attribute in the schema. Also the source column for the Action Timestamp (UTC) fact. |
datetime |
|
tran_date |
The date (in UTC timezone) when the transaction occurred. This is the source column of the Date attribute. |
date |
|
minute_id |
The minute (in UTC timezone) when the transaction occurred. This is the source column of the Minute attribute. See lu_minute for more information. |
int(11) |
|
local_timestamp |
The local timestamp when the transaction occurred. The local time hierarchy is specific to Badge transactions and is based on the timzone of the mobile device of the Badge App. This is the source column of the Local Timestamp attribute. |
datetime |
|
local_tran_date |
The local date when the transaction occurred. The local time hierarchy is specific to Badge logs and is based on the timezone of the mobile device of the Badge App. |
date |
|
local_minute_id |
The local minute when the transaction occurred. The local time hierarchy is specific to Badge transactions and is based on the timezone of the mobile device of the Badge App. This is the source column of the Local Minute attribute. |
int(11) |
|
action_type_id |
The Action Type ID corresponding to the specific action. This is the source column of the Action Type attribute. The full list of action types can be found in the section below. See lu_action_type for more information. |
smallint(6) |
|
mobile_app_id |
The Mobile App version ID which was used to log an Badge transactions. MicroStrategy Mobile stats are not tracked. See lu_mobile_app for more details. |
bigint(20) |
|
gateway_id |
The Identity gateway ID that was authenticated during a transaction. See lu_gateway section for more details. |
bigint(20) |
|
session_id |
The Microstrategy session used to log in to the Intelligence server and project to perform action. See lu_session for more details. |
bigint(20) |
|
os_id |
The OS ID used to log a Badge transactions. MicroStrategy OS version are not tracked. See lu_os for more details. |
bigint(20) |
|
device_id |
The device used to perform the action. For Badge actions it is the mobile device on which Badge or Communicator app is installed. For MicroStrategy, it is the IP address of the client machine. See lu_device for more details. |
bigint(20) |
|
execution_time |
The amount of time spent processing a MicroStrategy or Badge action (job) in milliseconds. This is the source column of the Execution Duration (ms) fact. |
double |
|
initial_queue_time |
The amount of time a job waited int he queue before starting to be processed in milliseconds. This is the source column of the Initial Queue Duration (ms) fact. |
int(11) |
|
prompt_answer_time |
The amount of time a job spent waiting for the user to input an answer to prompts required to execute the job in milliseconds. This is the source column of the Prompt Answer Duration (ms) fact. |
int(11) |
|
validating_account_id |
The Badge account that was validated by another Badge account. See lu_validating_account for more details. |
bigint(20) |
|
address_id |
The address_id corresponding to lat/long for a Badge transaction. This column is specific for Badge transactions. See lu_address for more details. |
bigint(20) |
|
facility_address_id |
The Facility street Address ID where the Badge transaction occurred. See lu_facility_address for more details. |
bigint(20) |
|
status_id |
The status (success/error) for each transaction. ID values less than 1 represents errors for Badge actions. Values greater than 3 represents errors on the Intelligence Server. See lu_status for more details. |
bigint(20) |
|
network_id |
The Network ID associated with the Badge transaction. All MicroStrategy actions are mapped to a default value. See lu_network for more details. |
bigint(20) |
|
beacon_id |
The Beacon ID associated with the Badge transactions. If no beacon was used in the transaction (i.e. open logical application) a default ID will be mapped. MicroStrategy transactions do not have beacons and therefore always map to a default value. See lu_beacon for more details. |
bigint(20) |
|
space_id |
The physical Space ID associated with the Badge transactions. If no beacon was used in the transaction (i.e. open logical application) a default ID will be mapped. MicroStrategy transactions do not have spaces and therefore always map to a default value. See lu_space for more details. |
bigint(20) |
|
application_id |
The logical Application ID associated with the Badge transactions. If no application was used in the transaction (i.e. open a physical space/door) a default ID will be mapped. MicroStrategy transactions do not have applications and therefore always map to a default value. See lu_application for more details. |
bigint(20) |
|
desktop_unlock_setting_id |
The configured Desktop Unlock Setting ID associated with the Badge transactions. If no Desktop was used in the transaction (i.e. open logical application) a default ID will be mapped. MicroStrategy transactions do not have Desktops and therefore always map to a default value. See lu_desktop_unlock_setting for more details. |
tinyint(4) |
|
parent_job_id |
The Parent Job ID for MicroStrategy actions. Not all actions have a Parent Job. If a document/dashboard based on datasets is executed, the dataset jobs will have the same document job as the Parent Job ID. The Parent Job ID can be used to link the dataset child jobs. This is the source column of the Parent Job attribute. |
bigint(20) |
|
job_id |
The Job ID corresponding to MicroStrategy execution actions. If a MicroStrategy action does not trigger a job, a default value will be mapped. This is the source column for the Job attribute. |
bigint(20) |
|
object_id |
The Object ID corresponding to MicroStrategy execution transaction. This could be a report, document, dashboard, or cube Object ID. For MicroStrategy Session transactions, there is no object; therefore, the project_id is used. See lu_object for more details. |
bigint(20) |
|
connection_map_id |
The Connection Map ID used for the MicroStrategy execution. Connection Map is only available for report and Cube execution. It represents the unique combination of database login, database instance, and database connection used in the execution. See lu_db_connection_map for more details. |
bigint(20) |
|
subscription_id |
The Subscription ID when an execution was a result of a subscribed report/document/dashboard. Not all MicroStrategy and Badge transactions have subscriptions and therefore a default value may be mapped. See lu_subscription for more information. |
bigint(20) |
|
bar_code_id |
The Bar Code ID associated with the Badge transactions. If no barcode was scanned in the transaction (i.e. open a physical space/door) a default ID will be mapped. MicroStrategy transactions do not have bar codes and therefore always map to a default value. See lu_bar_code for more details. |
bigint(20) |
|
history_list_message_id |
The History List Message ID corresponding to a MicroStrategy transaction. Not all transactions have History List Message and, therefore, a default value may be mapped. See lu_history_list_message for more details. |
bigint(20) |
|
desktop_id |
The Desktop ID associated with the Badge transactions. If no desktop was used in the transaction (i.e. open a physical space/door) a default ID will be mapped. MicroStrategy transactions do not have desktops and, therefore, always map to a default value. See lu_desktop for more details. |
bigint(20) |
|
recipient_id |
The Recipient ID represents the user who is subscribed to receive a subscription. This could be MicroStrategy user in the metadata or an external contact added by a MicroStrategy user. See lu_recipient for more details. |
bigint(20) |
| job_priority_id | The Job Priority ID represents the priority of a job to be executed and determines how long it will wait in the job execution queue. See lu_job_priority for more details. | int(11) |
|
total_queue_time |
The total amount of time a job spent waiting in queue (in milliseconds). This is the source column of the Total Queue Duration (ms) fact |
int(11) |
| row_count | The number of rows in the result set for an execution. This is source column for the Row Count fact. | int(11) |
|
step_count |
The number of job steps executed for an execution. This is the source column for the Step Count fact |
int(11) |
| sql_pass_count | The number of SQL passes used for an execution. This is the source column for the SQL Pass Count fact. | int(11) |
|
job_cpu_time |
The time a job spent processing on the CPU during execution. This column is the source for the CPU Duration (ms) fact. |
bigint(11) |
lu_action_type
The Action Type is type of action the user performs, for example creating a new subscription, exporting a report to PDF, or scanning a Badge QR code. The action type is a common attribute across both MicroStrategy and Badge transactions.
|
Column |
Description |
Data-Type |
|---|---|---|
|
action_type_id |
The numeric ID for the action type. |
smallint(6) |
|
action_type_desc |
The detailed type of action the user performs. |
varchar(255) |
|
action_category_id |
The numeric ID of the action category corresponding to the action type. |
smallint(6) |
lu_action_category
Action Category is a grouping of Action Types. It provides a broader analysis of user actions i.e. Executions or Badge Actions. The Action Category attribute enables filtering when analysis on a single type of transaction is desired.
|
Column |
Description |
Data-Type |
|---|---|---|
|
action_category_id |
The numeric ID for the action category. |
smallint(6) |
|
action_category_desc |
A categorization of types of actions a user performs. |
varchar(50) |
List of Action Categories and Types and their description:
A full list of Action Categories and Action Types are explained below. This list will continue to grow as Platform Analytics continues to process more detailed telemetry.
|
Action Category |
Action Type |
Explanation |
|---|---|---|
|
MicroStrategy Badge Actions
|
Access by Bluetooth | Indicates that a Badge app user unlocked a physical location when their smartphones are detected near a Bluetooth badge reader using the Badge app. |
|
Access by Key |
Indicates a Badge App user unlocked physical resources, such as locked doors or offices, by tapping a key in the Badge app on their smartphone. |
|
| Access by QR Code | Indicates a Badge app user logged in to a web application by scanning a QR code using the Badge app on their smartphone. | |
|
Bluetooth Discovery |
Indicates a Communicator app user discovered other Badge app users within the same vicinity by detecting the Bluetooth signal of other users. |
|
| Validate Badge by QR Code | Indicates one Badge app user validated another user by scanning their unique QR code. | |
|
Validate Badge by Usher Code |
Indicates one Badge app user validated another user by entering their Badge Code. The Badge Code is unique to each user and can be configured to change routinely. For example, this code can be given over the phone to identify yourself if you are talking to someone who does not know you. By default the Badge Code is 4 or 8 digits in length and updates every hour. |
|
| Badge Opened | Indicates a Badge user opened their badge app on their smartphone. | |
|
Windows Unlock by QR Code |
Indicates a Badge user signed in to their Windows computers by using their smartphone to scan a QR code displayed on their computer screen. |
|
| Access by Push Notification | Indicates a Badge user received a confirmation message (push notification) on their smartphone that has Badge app installed. The user must tap the confirmation message to verify her identity and finish logging in. | |
|
Badge Code as Second Password |
On the VPN login page, the user can type the Badge Code displayed on the Badge app on her smartphone in order to login. |
|
|
Single Sign-On |
Indicates a user logged in to a Badge web application using SAML authentication. |
|
|
Access by Beacon |
Indicates that a Badge user unlocked a physical locations when their smartphones are detected near a beacon, see. |
|
| Desktop Unlock | Indicates a Badge user paired a smartphone device with their Mac computer. | |
|
Desktop Unlock Pairing |
Indicates a Badge user paired a smartphone device with their Mac computer. |
|
| Scanned Barcode | Indicates a user scanned a barcode using the Badge App. The exact barcode string is stored in the lu_barcode table. | |
|
Generate Badge Code |
Indicates that a new badge code was generated on the Badge app. The Badge Code is unique to each user and can be configured to change routinely. By default, the Badge Code is 4 or 8 digits in length and updates every hour. |
|
| Agree to Badge Policy | Indicates that a user agreed to Badge Policy. | |
|
MicroStrategy Badge Management |
Delete Badge from Device |
Indicates that a user removes a badge from their Badge app on the mobile device. |
| Upload Badge Photo | Indicates a user uploads a new photo for their badge. | |
|
Device Enrollment Request |
Device enrollment requires a user to associate a mobile phone numbers with their Badges. Device Enrollment Request indicates a user submitted a request for a device enrollment code to be sent to a secure phone number. |
|
|
Device Enrollment Verified |
Once the device enrollment code is entered and verified successfully through the Badge app. |
|
|
MicroStrategy Badge Location Tracking
|
Location Tracking |
You can log when and where members of the network use the Badge app by enabling location tracking for a badge. Location Tracking indicates that the smartphone moved a 500m distance based on the long/lat values or 5 minutes. |
| Beacon Enter | Indicates a Badge app on smartphone was detected within the range of a beacon for the first time. The beacon must be configured to “log user location” in Network Manager. | |
|
Beacon Exit |
Indicates a Badge app on smartphone was detected leaving the range of a beacon. The beacon must be configured to “log user location” in Network Manager. |
|
| MicroStrategy Logins
|
Server Login | A user logged in to a MicroStrategy Intelligence Server. |
|
Server Logout |
A user logged out of a MicroStrategy Intelligence Server. When a user logs out of a server session, they are also automatically logged out of a project. |
|
| Project Login | A user logged in to a MicroStrategy Project manually. When a user logs into a project a server login is automatically created. | |
|
Project Logout |
A user logs out of a MicroStrategy Project manually. |
|
| Scheduler Login | A user logged in to a MicroStrategy Project by scheduler. When a user logs into a project a server login is automatically created. | |
|
Scheduler Logout |
A user logs out of a MicroStrategy Project by scheduler. |
|
| Cube Cache Hit | Download MSTR File with Cube Cache Hit | Indicates a user exported a dashboard object based on cube as an MSTR file and hits the cube cache. |
|
Execute with Cube Cache Hit |
Indicates a user executed a view report or a cube-based document or dashboard and hits the cube cache. |
|
|
Export to Excel with Cube Cache Hit |
Indicates a user exported a view report or a cube-based document to Excel and hits the cube cache. |
|
|
Export to PDF with Cube Cache Hit |
Indicates a user exported a view report or a cube-based document or a cube-based dashboard to PDF and hits the cube cache. |
|
| Export to CSV with Cube Cache Hit | Indicates a user exported a view report to CSV and hits the cube cache. | |
|
Export to Plain Text with Cube Cache Hit |
Indicates a user exported a view report to Plain Text and hits the cube cache. |
|
|
Export to HTML with Cube Cache Hit(Developer Only) |
Indicates a user exported a cube-based document to HTML from history list subscription and hits the cube cache. |
|
|
Cache Hit |
Execute with Cache Hit |
Indicates a user executed a report or a document or a dashboard and hits the cache. |
|
Export to Excel with Cache Hit |
Indicates a user exported a normal report or a report-based document to Excel and hits the cache. |
|
|
Export to PDF with Cache Hit |
Indicates a user exported a normal report or a report-based document or a report-based dashboard to PDF and hits the cache. |
|
|
Export to CSV with Cache Hit |
Indicates a user exported a normal report to CSV and hits the cache. |
|
|
Export to Plain Text with Cache Hit |
Indicates a user exported a normal report to Plain Text and hits the cache. |
|
| Cache Creation | Execute and Create Cache | Indicates a user executed a report or a document or a dashboard or a cube and creates a cache. |
|
Cube Modifications |
Delete Cube Cache
|
To change the intelligent cube status, right-click the Cube in the Cube Monitor, and select one of the actions. Cube Delete indicates a user removed a published Intelligent Cube as an accessible set of data for multiple reports from the Cube Monitor. |
| Activate Cube Cache | To change the intelligent cube status, right-click the Cube in the Cube Monitor, and select one of the actions. Cube Activate Loads a previously deactivated Intelligent Cube as an accessible set of data for multiple reports. | |
|
Deactivate Cube Cache |
To change the intelligent cube status, right-click the Cube in the Cube Monitor, and select one of the actions. Cube Deactivate removes an Intelligent Cube instance from Intelligence Server memory, but saves it to secondary storage, such as a hard disk. |
|
|
Load Cube Cache |
To change the intelligent cube status, right-click the Cube in the Cube Monitor, and select one of the actions. Loading a cube moves an Intelligent Cube from your machine’s secondary storage to Intelligence Server memory. |
|
|
Unload Cube Cache |
To change the intelligent cube status, right-click the Cube in the Cube Monitor, and select one of the actions. Unloading a cube moves an Intelligent Cube from Intelligence Server memory to your machine’s secondary storage, such as a hard disk. |
|
|
Execution
|
Download MSTR File |
Indicates a user exported a dashboard object based on report datasets as an MSTR file. |
|
Execute |
Indicates a user executed a report or a document or a dashboard without hitting any cache. |
|
|
Execute and Export to HTML(Developer Only) |
Indicates a user exported a report-based document to HTML from history list subscription without hitting any cache. |
|
|
Execute and Export to Excel |
Indicates a user exported a normal report or a report-based document to Excel without hitting any cache. |
|
| Execute and Export to PDF | Indicates a user exported a report-based document or dashboard to PDF without hitting any cache. | |
|
Execute and Export to CSV |
Indicates a user exported a report to CSV without hitting any cache. |
|
| Execute and Export to Plain Text | Indicates a user exported a report to Plain Text without hitting any cache. | |
|
Execute Report SQL View |
Right Click a normal report and view SQL in Developer. |
|
| Execute with Dynamically Sourced Cube Cache Hit | Indicates a user exported a report using a dynamically sourced cube and hit the cache. | |
|
Cube Executions
|
Republish cube data via update |
The Intelligence Cube is updated (republished) based on the cube republish settings. The Intelligence Cube’s Republish Policy is evaluated. If the data returned is already in the Intelligent Cube, it is updated where applicable. (If we have multiple table sources, all of them should have the same Republish Policy) |
|
Republish cube data via append |
The Intelligence Cube is updated (republished) based on the cube republish settings. The Intelligence Cube’s Republish Policy is evaluated. If new data is available, it is fetched and added to the Intelligent Cube. (If we have multiple table sources, all of them should have the same Republish Policy). |
|
|
Republish cube data dynamically |
The Intelligence Cube is updated (republished) based on the cube republish settings. The Intelligence Cube’s Republish Policy is evaluated. If a new data is available, it is fetched and added to the Intelligence cube, and data that no longer meets the filter's criteria is deleted from the Intelligent Cube. (If we have multiple table sources, all of them should have the same Republish Policy). |
|
|
Republish cube data via upsert |
The Intelligence Cube is updated (republished) based on the cube republish settings. The Intelligence Cube’s Republish Policy is evaluated. If new data is available, it is fetched and added to the Intelligent Cube, and if the data returned is already in the Intelligent Cube, it is updated where applicable. (If we have multiple table sources, all of them should have the same Republish Policy). |
|
|
Refresh cube data by appending via filter |
The incremental refresh filter is evaluated. If new data is available, it is fetched and added to the Intelligent Cube. Data that was already in the Intelligent Cube is not altered. |
|
|
Refresh cube data by deleting via filter |
The incremental refresh filter is evaluated. The data that meets the filter’s definition is deleted from the cube. For example, if the Intelligent Cube contains data for 2008, 2009 and 2010, and the filter returns data for 2009, all the data for 2009 is deleted from the cube. |
|
|
Refresh cube data by updating via filter |
The incremental refresh filter is evaluated. If the data available is already in the Intelligent Cube, it is updated where applicable. No new data is added to the Intelligent Cube. |
|
|
Refresh cube data by upserting via filter |
The incremental refresh filter is evaluated. If new data is available, it is fetched and added to the Intelligent Cube, and if the data returned is already in the Intelligent Cube, it is updated where applicable. |
|
|
Refresh cube data by appending via report |
The incremental refresh report is evaluated. If new data is available, it is fetched and added to the Intelligent Cube. Data that was already in the Intelligent Cube is not altered. |
|
|
Refresh cube data by deleting via report |
The incremental refresh report is evaluated. The data that meets the report’s definition is deleted from the cube. For example, if the Intelligent Cube contains data for 2008, 2009 and 2010, and the filter returns data for 2009, all the data for 2009 is deleted from the cube. |
|
|
Refresh cube data by updating via report |
The incremental refresh report is evaluated. If the data available is already in the Intelligent Cube, it is updated where applicable. No new data is added to the Intelligent Cube. |
|
|
Refresh cube data by upserting via report |
The incremental refresh report is evaluated. If new data is available, it is fetched and added to the Intelligent Cube, and if the data returned is already in the Intelligent Cube, it is updated where applicable. |
|
| Cube Publish | Indicates a user published an intelligence cube from any tool (Web, Developer, etc). The Intelligent Cube's SQL is re-executed, and all the data is loaded from the data warehouse into Intelligence Server's memory. | |
|
Republish DI Cube with Multi-refresh Policies |
The Intelligence Cube is updated (republished) based on the cube republish setting. The Intelligence Cube’s Republish Policy is evaluated. If we have different (multiple) policies for different tables, the data will be updated based on its settings. |
|
| Edit | Edit in Design Mode | Indicates a user opened document or dashboard in Design Mode. |
|
Manipulations
|
Export to PDF |
Indicates a grid or a visualization in a dashboard is exported to PDF after dashboard is executed. |
|
Export to HTML(Developer Only) |
Indicates a grid or a visualization in a dashboard is exported to HTML after dashboard is executed. |
|
| Export to CSV | Indicates a grid or a visualization in a dashboard is exported to Data after dashboard is executed. | |
|
Export to Plain Text |
Indicates a grid or a visualization in a dashboard is exported to Plain Text after dashboard is executed. |
|
| Export to Excel | Indicates a grid in a dashboard is exported to Excel after dashboard is executed. | |
|
Manipulation |
Indicates a user manipulated a dashboard, for example, apply a filter element. |
|
| Partial Dataset Execution | Indicates a user executed a report-based document from developer | |
|
Modify History List Messages |
Change History List Message Status |
Indicates a user modified the history list message. A modification can be changing the status from read to unread or vice versa. |
|
Create History List Message |
Indicates a MicroStrategy user created a History List message, see Adding reports and documents to the History List. |
|
|
Delete History List Message |
Indicates a MicroStrategy user deleted a History List Message, see Maintaining your History List. |
|
|
Rename History List Message |
Indicates a MicroStrategy user renamed the History List Message, see Maintaining your History List. |
|
|
View History List Message |
Indicates a MicroStrategy user viewed the History List Message of a report, document, dashboard, see About viewing reports and documents in your History List. |
Status (errors)
The Status and Status Category attributes are used to track the success/failure for both MicroStrategy and Badge transactions.
Status Category provides a high level grouping to analyze individual error messages. Status is the exact error message that is recorded in the logs. Most errors in the logs are recorded at the unique job and session level. Therefore, when trying to determine what is the "most frequent error," which occurs in a MicroStrategy environment, a count of errors at the Status level almost always results in 1. To analyze an aggregated errors in the system, create a report with the count (status) at the level of Status Category. Status Category is a parent of Status.
lu_status_category
The categorization of an action status recorded in the logs.
|
Column |
Description |
Data-Type |
|---|---|---|
|
status_category_id |
The auto-generated numeric ID of the status category. |
smallint(6) |
|
status_category_desc |
The categorization of the actions status. The elements include, Success - indicates a successful transaction for both Badge and MicroStrategy action types. Database Error Occurred - indicates that an issue occurred at the database level causing the problem. Failed Subscription Delivery - indicates that delivery of a subscribed object was unsuccessful. Cancelled - indicates that the job/action was cancelled before it could finish. Denied – a Badge transaction failed. Error message category generated by MicroStrategy Intelligence server. |
varchar(25) |
lu_status
The status of whether the action by the user was successful, denied, or resulted in a specific error message. For Badge, there is set list of denied types. For MicroStrategy the exact error message is recorded. The status_desc column stores the exact error message recorded from the Intelligence Server logs and can be used to analyze the unique job execution details.
|
Column |
Description |
Data-Type |
|---|---|---|
|
status_id |
The auto-generated numeric ID of the status |
bigint(20) |
|
status_desc |
The status of whether the action by the user was successful, denied or resulted in a specific error. The elements include, VPN Access Denied- A denied action that occurs when trying to log in to VPN Badge gateway. Physical Access Denied- A denied action that occurs when trying to access a physical space that you are unauthorized to access. Push Notification Denied - A denied action that occurs when trying to approve access via push notification. QR Code Expired- A denied action that occurs when scanning a QR code that has expired. Invalid Badge- A denied action that occurs when trying to access one network with another networks badge. Denied- when Badge cannot determine why there was a failure the generic "Denied" status is assigned. error message generated by MicroStrategy Intelligence Server. |
varchar(4096) |
|
status_category_id |
The numeric ID of the status category corresponding to the action status. |
smallint(6) |
|
db_error_indicator |
A flag representing whether the status was the result of a database error. |
tinyint(4) |
| cancel_indicator | A flag representing whether the job was cancelled or not. | tinyint(4) |