BMC Remedyforce Troubleshooting Document

Transcription

1 Troubleshooting Document BMC Remedyforce Troubleshooting Document September 2015

2 Table of Contents 1.0 Salesforce Apex Governor Limits Overview SOQL Queries Limits Triggers and Order of Execution Analyze - How to find out the root cause Is this issue caused due to customization over Remedyforce? Is this issue caused due to Remedyforce code? Is this issue caused after upgrading Remedyforce application? Some workarounds for this type of issue Note Summary 9 PAGE 1 OF 10

3 1.0 Salesforce Apex Governor Limits Overview Governor limits are runtime limits enforced by the Apex runtime engine. Because Apex runs in a shared, multitenant environment, the Apex runtime engine strictly enforces a number of limits to ensure that code does not monopolize shared resources. Governor limits guarantee that no implementation of Apex will negatively impact other salesforce.com instances. It very important to understand the Governor Limits Scope - The limits will be applied to the code that executes beginning at that entry point, running through all subsequent code that is called until the code terminates. For example, say an incident record is created and that causes an Incident Apex trigger to initiate. This Incident trigger performs few queries, and then inserts some related IncidentHistory and Task records. The IncidentHistory and Task objects also have triggers enabled, which are subsequently invoked. All of the triggers and related code that is executed are considered as part of the same Apex request and therefore share the governor limits began counting when that initial Incident trigger was invoked. Any Apex class, method, or trigger invoked by code executed within the entry point will count towards the same governor limits as it's a synchronous request. Per-Transaction Apex Limits These limits count for each Apex transaction. For Batch Apex, these limits are reset for each execution of a batch of records in the execute method. The following table lists the limits for synchronous Apex and asynchronous Apex (Batch Apex and future methods) when they are different. Otherwise, this table lists only one limit that applies to both synchronous and asynchronous Apex. Description Synchronous Limit Asynchronous Limit Total number of SOQL queries issued Total number of records retrieved by SOQL queries 50,000 Total number of SOSL queries issued 20 Total number of records retrieved by a single SOSL query 2,000 Total number of DML statements issued Total number of records processed as a result of DML statements, Approval.process, or Database.emptyRecycleBin 10,000 Total heap size 6 MB 12 MB Total number of records retrieved by Database.getQueryLocator 10,000 Total number of callouts (HTTP requests or Web services calls) in a transaction 100 Maximum CPU time on the Salesforce servers 2 10,000 milliseconds 60,000 milliseconds Maximum execution time for each Apex transaction 10 minutes Maximum number of unique namespaces referenced 10 1 DML statements such as insert, update, delete, upsert etc. are included in the total number of DML statements. 2 CPU time is calculated for all executions on the Salesforce application servers occurring in one Apex transaction. CPU time is calculated for the executing Apex code, and for any processes that are called from this code, such as package code and workflows. Note Governor Limits apply to each testmethod. PAGE 2 OF 10

4 2.0 SOQL Queries Limits Total number of SOQL queries issued per apex transaction for a synchronous transaction is 100 and for an asynchronous transaction, 200 SOQL queries are issued. Certified managed packages, that is, managed packages that have passed the security review for AppExchange, get their own set of limits for per-transaction limits with the exception of some limits. Certified managed packages are developed by Salesforce ISV Partners, are installed in your organization from Force.com AppExchange, and have unique namespaces. Here is an example that illustrates the separate certified managed package limits for DML statements. If you install a certified BMC Remedyforce managed package, all the Apex code in that package gets its own 100 SOQL queries limit for synchronous Apex. These SOQL queries are in addition to the 100 SOQL queries your organization s native code (such as custom triggers) can execute. This limit increase means more than 100 SOQL queries might execute during a single transaction if code from the managed package and your native organization both execute. Similarly, the certified managed package gets its own 150 DML statements, in addition to the organization s native code limit of 150 DML statements, and so on. All per-transaction limits count separately for certified managed packages with the exception of: The total heap size The maximum CPU time The maximum transaction execution time The maximum number of unique namespaces These limits count for the entire transaction, regardless of how many certified managed packages are running in the same transaction. Organization s native code limit usage (Namespace - default) PAGE 3 OF 10

5 Certified managed package limit usage (Namespace - BMCServiceDesk) 3.0 Triggers and Order of Execution When you save a record with an insert, update, or upsert statement, Salesforce performs the following events in order. Note Before Salesforce executes these events on the server, the browser runs JavaScript validation if the record contains any dependent picklist fields. The validation limits each dependent picklist field to its available values. No other validation occurs on the client side. On the server, Salesforce: 1. Loads the original record from the database or initializes the record for an upsert statement. 2. Loads the new record field values from the request and overwrites the old values. If the request came from a standard UI edit page, Salesforce runs system validation to check the record for: Compliance with layout-specific rules, Required values at the layout level and field-definition level, Valid field formats, Maximum field length. 3. Executes all before triggers. 4. Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. 5. Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record is not saved and no further steps, such as after triggers and workflow rules, are taken. 6. Saves the record to the database, but doesn't commit yet. 7. Executes all after triggers. 8. Executes assignment rules. 9. Executes auto-response rules. 10. Executes workflow rules. 11. If there are workflow field updates, updates the record again. PAGE 4 OF 10

6 12. If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time, in addition to standard validations. Custom validation rules and duplicate rules are not run again. 13. Executes processes. If there are workflow flow triggers, executes the flows. 14. Executes escalation rules. 15. Executes entitlement rules. 16. If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record. Parent record goes through save procedure. 17. If the parent record is updated, and a grandparent record contains a roll-up summary field or is part of a crossobject workflow, performs calculations and updates the roll-up summary field in the grandparent record. Grandparent record goes through save procedure. 18. Executes Criteria Based Sharing evaluation. 19. Commits all DML operations to the database. 20. Executes post-commit logic, such as sending . Note During a recursive save, Salesforce skips steps 8 (assignment rules) through 17 (roll-up summary field in the grandparent record). 4.0 Analyze - How to find out the root cause From the debug logs, you got how to find out the flow of execution, verifying at first level what is causing the issue, and so on. Further, analyze to find some solutions for it. Until you do not know whether this issue occurred due to customization or loop whole in the Remedyforce code, no solution or workaround could be suggested. 4.1 Is this issue caused due to customization over Remedyforce? There are several causes due to customization. Below are some of the Salesforce features that might cause this issue: Reason Custom code Description Customer may create their custom triggers on Remedyforce objects such as Incident, Task, Change Request, and so on for achieving their business needs. Therefore, they might use DML statements (such as, insert, update, delete) in their custom trigger code. Whenever DML statements are executed, triggers are executed one more time. There could be potential areas in custom code (trigger) which are kind of hotspots. For example: Query in a loop If SELECT queries or DML statements are executed in a loop (for loop, while loop, and so on), these loops might cause the issue. It is not a best practice to have queries in a loop. An after trigger Mostly an After event in a trigger is used to perform updates or to create new records based on old records. So this again could be the reason for Too Many SOQL issue. Recursive updates If a custom code contains recursive call where updates are performed, triggers are executed multiple times. PAGE 5 OF 10

7 Approval process Whenever a new record is created, it could be submitted for approval automatically. For example, in BMC Remedyforce, there is a setting for submitting service requests created from Self Service to submit it automatically for approval. Therefore, the approval process is executed in the same transaction. Workflow rules Customers might create workflow rules to automate their business process. If these workflow rules contain field update actions, triggers are executed again. Field updates from all workflow rules that satisfy entry rule criteria, are in a single code unit. Therefore, for such workflow rules, all field update actions trigger will get executed only once. But workflow rules get triggered every time whenever AfterInsert, AfterUpdate events of trigger finishes their execution. Some workflow rules might be configured to re-evaluate every time or are evaluated whenever a record is edited. Such workflow rules perform same field updates each time unnecessarily. Flows or process builders Visual Workflows allow you to automate business processes by building applications, known as flows that collect, update, edit, and create Salesforce information. Similarly, customers can also use the more powerful and flexible Process Builder to perform the same actions as workflow. This feature is recently introduced by Salesforce. The process builder does not support outbound messages, but you can create one with Apex. With the Process Builder, you can: Create a record Update any related record not just the record or its parent Use a quick action to create a record, update a record, or log a call Launch a flow you can t schedule this action with workflow Submit for approval These actions might execute triggers. For example, customers might want to create an IncidentHistory record on creating an Incident record or to create a task record depending on the values of the task that is being created. Roll-up Summary fields Roll-up summary fields may cause to execute triggers on an object on which this field is been created. If the record of Summary Object is created or updated, then triggers of an object, on which roll-up summary field is created, will get executed as this field gets updated (depending on the aggregate function i.e. Summary Type used for this field). For example, while submitting a service request from self-service, service target might get applied to that record. If a roll-up summary field is created on Incident object with Summary Object as Incident Service Target and Summary Type as Count, then after applying SLA (Incident Service Target records are created by means of applying SLA) to an incident it will cause to execute Incident trigger to update this field as it is storing Incident Service Target record count (to count how many service targets are applied that particular incident). Again this scenario varies based on the aggregate function used in the Roll-up Summery type field. PAGE 6 OF 10

8 4.2 Is this issue caused due to Remedyforce code? The Too Many SOQL Queries-101 issue rarely happens due to the Remedyforce code. However, the real cause of the issue can be identified from the debug log only. If the Remedyforce triggers are executed multiple times without any customization (for example if there are no custom workflow rules, flows or process builder items, custom triggers, and so on), the issue might be caused due to Remedyforce code. There might be some case where customer scenario or use case is complex such as Task templates and Change Request templates are linked to an SRD, also SLA gets applied in same transaction and more. In such cases, it becomes difficult to find the solution. 4.3 Is this issue caused after upgrading Remedyforce application? Some customers may report that this issue is caused after upgrading to the latest version of BMC Remedyforce. The reason behind this behavior might be that in every release, an enhancement might be added to an existing feature or a new feature is added. New code might consume some minimum number of SOQL queries. However, it is rare. This issue is totally dependent upon customer scenario or use case for which they are facing problem. They might have already customized the product with the features that causes this issue; but due to some of the new features added to Remedyforce it might seem that the issue has occurred due to latest BMC Remedyforce upgrade. There might be a case that SOQL limit was already closer to 100 and with the upgrade to the latest release, new features might consume some SOQL queries. However, there problems might arise due to the Remedyforce code after upgrading. But you need to find whether the cause of the issue is customization or Remedyforce code. 5.0 Some workarounds for this type of issue To resolve Too Many SOQL-101 issues that are caused due to customization in Remedyforce can be resolved with some workarounds. In such cases, customers need to change their customization in one of the suggested ways so that their business use cases are implemented and the Too Many SOQL-101 issue does not occur. Workaround for this type of issue varies from customer to customer. Workaround depends on customer scenario or business use-case. According to the cause of the issue, you can apply any of the workaround listed below: 1. Optimize custom code Ask customer to avoid using queries inside for loop and use List, Map, or Set classes to store the result of queries and then use loop on this stored data. Suggest customer to avoid using DML statements inside a custom trigger. If they cannot avoid it, they can use DML statements in Future methods or any Force.com feature that is executed in separate asynchronous transactions. 2. Custom trigger with before events Even though workflows with field update actions are easier to create and manage, such workflows fire before update triggers and after update triggers one more time and hence consume more SOQL queries. Therefore, to update fields, instead of using workflow rules create a custom trigger with before events (before insert/update). The advantage to update fields by using a custom trigger is that as the field updates are done before saving the record to database (but before commit) and it does not require using DML statements to update the record. For example: if(trigger.isbefore) { for(bmcservicedesk Incident c inc : Trigger.new) { inc.bmcservicedesk FKImpact c = newimpactval; inc.bmcservicedesk FKUrgency c = newurgencyval; inc.bmcservicedesk FKCategory c = newcategoryval; } } Use such code. Do not use: update inc; PAGE 7 OF 10

9 As we are updating values in a before event, it will automatically take the updated value. If you update these values in an after event, you must need to use DML statements, such as update inc; as record is saved in database and then after triggers are executed. 3. Apex future method In some cases, it is not possible to use custom triggers with before events such as updating incident record after inserting incident-history records. In such cases, in after triggers, you can call the Apex future methods to update the parent record. An Apex future method is executed in a separate asynchronous transaction. 4. Use Remedyforce Templates instead of field update actions The field update actions from workflow rules and Initial Submission Action in an Approval Process can be removed and moved to an Incident template linked to the service request or can be moved to respective template for which module issue has occurred. 5. Map User Inputs to Template Fields in SRD Mapping input fields to template fields is useful for customers if they want to update the Incident, Task, and Change Request object fields with user inputs entered on a Ticket page. Many customers do field updates using workflow rules with field update action. But instead of this, mapping user input fields to template fields in an SRD helps customers to achieve the same business use-case which could be avoid causing Too Many SOQL issues. 6. Change the workflow rule evaluation criteria Some workflow rules are triggered when a record is created, and every time it is edited. You can change evaluation criteria to of such workflow rules to: created, and any time a record is edited to subsequently meet criteria as this will be evaluated unless there is change in respective field value. Some field update actions in workflow rules are configured with Re-evaluating rules. You must avoid using Re-evaluating rules. 7. Use BeforeInsert/BeforeUpdate events of trigger The workflow rules and their field update actions can be implemented in BeforeInsert or BeforeUpdate events of a trigger. For example, GMF - Update Service to Equal Parent Cat workflow rules apply service after creating a record. Therefore, it would be feasible if a service is applied while creating a record that means implementing workflow rule in BeforeInsert event of the Incident trigger. The workflow rule entry criteria can be implemented as IF-ELSE conditions in code. 8. Verify SLA criteria & use RF Templates Some of the workflow rules are created to populate default values. If these default values are used in SLA criteria, then SLA will get applied after workflow rules get executed. This situation can be avoided by moving these default values being populated through WF rule field updates into Remedyforce Templates or by creating custom before triggers. So that these workflow rules are not triggered and also service targets are applied in AfterInsert event of the Incident trigger. 9. Flows with Wait element You can use Salesforce Visual Flows. In Visual Flows, the Wait element can be added as a first step (should be the starting point) so that the later actions in flows will be executed in separate transactions. Customers can specify minimum waiting time. Flows with the Wait element span multiple transactions. This behavior can help you to exceed your Apex governor limits if the resumed interview executes DML operations or SOQL queries through Flow elements, such as Record Create/Update or Fast Lookup, Apex triggers, Immediate workflow actions. PAGE 8 OF 10

10 10. Use time-based workflow actions Time-based workflow rule actions can be used instead of Immediate workflow rule actions so that it the workflow rule is executed in separate transaction and issue is avoided. 11. Deactivate custom workflow rules Deactivating workflow rules may not be useful for customers; but it may be required for resolving some complex issues. 6.0 Note Also, there might be some scenarios where deactivating a workflow rule does not impact as it really may not be necessary. For example, say customer has created a custom field Last Action on Incident to track last history of an incident record. But all actions that take place on incident are being tracked and we can see the overall history records in Action HistoryorIncident History related list. There is no way that Salesforce can increase the governor limit or can stop it; so best practices need to be followed. These are hard limits on your org preventing you, for example, from doing too many SOQL queries in a trigger (maximum: 100 queries). Upgrading your edition or paying Salesforce more money will not increase your limits! The only workaround is to understand how to navigate around them. Idea is been submitted for the same on IdeaExchange. In the past, the SOQL governor limit was raised from 20 to 100. You can increase the number of SOQL queries now for future method with the following But this feature is in Beta. Salesforce provide this feature to selected customers through a pilot program that requires agreement to specific terms and conditions. To be nominated to participate in the program, contact Salesforce. Pilot programs are subject to change, therefore, Salesforce cannot guarantee acceptance. 7.0 Summary Writing efficient and scalable Apex code is critical to the overall success of your Apex solution. Understanding the reasons why governor limits exist and how they are calculated is important in achieving this. Governor limits are not intended to limit your Apex solutions or prevent you from writing rich, complete solutions. Instead, they are enforced to ensure that efficient and scalable code is executing on the Force.com platform in a shared, multitenant environment. 8.0 References BMC delivers software solutions that help IT transform digital enterprises for the ultimate competitive business advantage. W e have worked with thousands of leading companies to create and deliver powerful IT management services. From mainframe to cloud to mobile, we pair high-speed digital innovation with robust IT industrialization allowing our customers to provide amazing user experiences with optimized IT performance, cost, compliance, and productivity. We believe that technology is the heart of every business, and that IT drives business to the digital age. BMC Bring IT to Life. PAGE 9 OF 10