This blog elaborates on the different processes in Microsoft Dynamics CRM, high-level definitions,how logs for these processes impact Application Performance. Also, the Impact of Tidying Up the Process Session Logs (Dialog Session) in Microsoft Dynamics CRM. (Also applies for older versions of Microsoft Dynamics CRM 2011 onwards).
In Microsoft Dynamics CRM, a process is an automated workflow which performs defined actions by fulfilling conditions and rules in each of the steps before processing next steps. There are four categories of processes: a Business Process Flow, a Workflow, a Dialog and an Action.
The Application performance will always have a dependencyon the Database Size,.Ta major factor in Microsoft Dynamics CRM Application.. The database size for the Microsoft Dynamics CRM will be impacted significantly by the Business Process Flow, Dialog and Workflow related tables. There is a huge amount of online information and Microsoft provided data available for maintenance of Workflows related tables. Business Process Flow and Action are the newly introduced functionality, so there will be further information on the challenges in future.
Dialogs are a type of System Jobs in Microsoft Dynamics CRM, but the ProcessSession is the name of the Table which contains the execution logs for the Dialog each time the Dialog is executed. It maintains details about the execution of each session. A Process Session is nothing but a Dialog Session and the Microsoft Dynamics CRM Database View names are mentioned instead of the actual table names in the Microsoft Dynamics CRM Database, To verify the references, the view names need to be mentioned to run queries against the Microsoft Dynamics CRM Database Views.
3. ProcessSession Table, Related Database Tables and their association:
Execution is done by the User Interface with the help of the Wizard with each of the wizard pages classified as a step. Each of these steps could have the user input or data processing information. The ProcessSession Table is associated with the number of tables where references are saved for executions and the status of each step during execution of the Dialog. In Microsoft Dynamics, every record can be referenced with the help of a GUID (Global Unique Identifier),a 32 Digit alpha-numeric value.
The ProcessSession Table has a relationship with two of the tables in Microsoft Dynamics CRM Tables:
3.1 Association with Tables:
Each time a Dialog is executed, an entry is created in the PrincipalObjectAccess (POA) Table and the WorkflowLog Table. The PrincipalObjectAccess table contains the ObjectId and the ObjectTypeCode as reference to the corresponding WorkflowLog Record. These records stay as references until the corresponding WorkflowLog record is deleted from the WorkflowLog Table. As the size of the PrincipalObjectAccess table increases, there is definite impact on the overall application performance.
The record creation in the PrincipalObjectAccess Table is the predictable conduct as records created by other processes (Business Process Flow & Workflow) also create a corresponding record in the PrincipalObjectAccess Table. As the dialog is also a type of Process similar to that of the Workflow and Business Process Flow, a reference entry is created in the WorkflowLog Table which is referenced by the ObjectId in the PrincipalObjectAccess Table. However, when a Workflow is executed, an entry for the actual object is done in the AysncOperation Table, but when the Dialog is executed,a record is created in the ProcessSession Table and for the Business Process Flow execution, an entry is created in the BusinessProcessFlowInstance Table.
Usually,in most of the Microsoft Dynamics CRM Implementations, the PrincipalObjectAccess Table is maintained so that the size of the table does not grow too large. However,most Dynamics Developers and Architects manage clearing of the AsyncOperation table which will tidy up the respective entries in the PrincipalObjectAccess Table and WorkflowLog Tables.
To tidy up and delete the Dialog related Database tables, it is recommended to use the Bulk Delete Operation..
4. Significance of Data in the ProcessSession Table and Associated Tables:
4.1 Table Definitions:
1. ProcessSession Table:
A ProcessSession (Dialog Session) represents a dialog session that is created each time the user runs or executes a dialog process - containing the Logs about the session such as the user who ran it, time when it was started and completed, actions performed during the running of the dialog process and so on.
2. WorkflowLog Table:
A WorkflowLog stores the status or result (success, failure or cancelled) of each of the steps of a dialog or a process that is executed, for both workflows and the dialogs.
3. PrincipalObjectAccess (POA) Table:
POA (PrincipalObjectAccess) Table is the table which contains data of the records sharing i.e., whenever a record is accessed that is not owned by the logged in user the CRM Service will check the POA if the person has the privilege after which the user can access the record. Each time the privilege check is done, there is an entry made in the POA Table.
The Process Session contains the records created each time a dialog is run or executed with details such as the user who has run it, the time and the status of the executions and the actions performed during the dialog process for the respective session.
Each time there is an entry recorded in the ProcessSession table, duplicatee entries are created in the WorkflowLog, with details of each of the steps executed during the dialog session. Correspondingly it will create equal number of records in the POA Table. As each of the process session record is accessed, an entry is made in the POA Table.
As mentioned in the earlier sections, the ProcessSession Table contains the records which refer to the data during execution of the particular session, which will be recorded during execution by Users depending on which Dialog would be successful, failed or cancelled. This data in the Process Session table would most probably not be required for future references, or there can be a frequency, or the Validity of this Data can be defined around the same, depending on the functionality and Process of the Application and Business Requirements. A probable requirement of this data for the entries older than 6 months would not be required. These records can be deleted using the Bulk Delete Operations. Hence, the associated records present in the WorkflowLog and the POA Table are deleted as well.
Note: The deletion of the data from the ProcessSession Table will delete the associated records from the WorkflowLog and the POA Table as well, resulting in reduction of the record count for all three database tables.
6. Steps for Setting Up the Bulk Delete Job the Process Sessions:
Note: Make sure the above-mentioned Bulk Delete Job does not clash with any other Bulk Delete or Application and is recommended to be executed Out of Business Hours.
The setting up of the bulk delete job will help in clearing all records from the Process or Dialog Sessions, which will tidy up the WorkflowLog and the POA Tables as well.
As the Dialog is just another Process in Microsoft Dynamics CRM same as that of the Workflow. They do not run under Async and do not hold entry in the AsyncOperation, however they hold an entry in the WorkflowLog Table.iIt is generally understood that the Dialogs work the same way, except that they are executed in the ProcessSession Table instead of the AsyncOperation. It also holds the entries into the POA Table for the associated entries.