Archer Configuration Best Practices

Transcription

1 Archer Configuration Best Practices RSA Archer Professional Services November 2016 Overview This document contains best practice suggestions to consider when setting up the infrastructure for your Archer environment and when configuring applications within the Platform. Important: RSA strongly recommends that before applying changes to your Archer instance, you have a complete understanding of what you are doing and why. Never move forward with changes without being aware of any possible negative consequences. Archer Server Setting Recommendations Recommended Database Settings in SQL Server Management Studio The Archer database server Max Degree of Parallelism should be set to 1. o Alternative values (e.g. 4 or 8) may provide better performance, but as a general rule, 1 is more performant than 0 and/or other values. The Archer database server should be configured for one tempdb data file per physical core (max 8). o Tempdb data files should be sized equivalently and should be large enough to minimize the size fluctuations associated with Autogrowth. o Autogrowth should be set to grow by a specific size (rather than a percentage). To verify the version number, see the bottom of the screen. Archer database indexes should be rebuilt and statistics should be updated on a regular basis. o The Archer database must be maintained during ongoing operations. o Two SQL jobs, which are located in the Installation Tools folder, are supplied with the product. Alternatively, you can use your existing jobs for implementation. The recovery model for the Archer database should be set to Simple. Auto Shrink should be set to False for the Archer database. Important: Deviation from the recommendations listed above may negatively affect performance. Archer Services The keyword index folder should be located on the same server as the queuing service. It should not be located on a NAS. Attachments should only be indexed if there is a business need. (This is a field-level definition). The queuing service should only be registered and running on one server. You should always use UNC paths to reference paths in the Archer Control Panel. 1

2 Archer Application Configuration There are several issues to consider when trying to enhance the performance and foster the usability of an Archer application. Design It is important to have a design phase before beginning the implementation process. Plan your design before attempting to build a solution. Adhere to the out-of-the-box design as much possible. Pencil to paper first! Work backwards from desired reports to form your design. If you plan on creating an on-demand application, verify that it does not duplicate the functionality of any Archer core applications. The Less is More Approach Keep your layouts simple and use fewer data-driven events, calculations, tabs, and fields to improve performance. Less is More Guidelines: Keep naming conventions simple: o Workspace and Dashboard names should be kept between 1-3 words. o iview names should be 5 words or less. o Application and Solution names should be 3 words or less. o Section names should be 2 words or less. o Report names should be 5 words for less. Keep the number of fields displayed on a layout below 500. Displaying more than 500 fields can impact performance. Keep the number of root tabs displayed on a layout below 10. Displaying more than 10 root tabs can impact performance. Keep the number of child tabs displayed on a layout below 20. Displaying more than 20 child tabs can impact performance. Keep the number of data driven events below 100. Applying more than 100 events or more can impact performance. Keep the number of Apply Conditional Layout (ACL) events below 25. Applying more than 25 ACL events can impact performance. Keep the number of record permissions below 10. Applying more than 10 record permissions can impact performance. Applying more than 20 record permissions requires a different approach. Keep the number of cross reference fields below 20. Displaying more than 20 cross reference fields can impact performance. Keep the number of total references below 500. Displaying more than 500 total references can impact performance. Keep the number of questions on a questionnaire below 300. Including more than 300 questions on a questionnaire can impact performance. When using the grid view, check your display settings for Cross-Reference or Related Records fields. The number of fields and records displayed can slow down performance. Review the number of displayed rich text controls. The number of displayed rich text controls can slow down performance. 2

3 Unless a well-defined and succinct selection is available, Permissions and User Group fields must use the Values Pop-Up control. The Dropdown control offers fewer clicks for small selections, but large collections can make it more difficult to find items. Cross-Reference / Related Record grids should display the key field as the left-most field. Limit the use of outside scripts (e.g. JavaScript) as much as possible. Configure First Published and Last Updated date fields to be off-layout. These items are shown in the page header by default and do not need to be placed on the layout. Note: Include a description on every Workspace, Dashboard, Application, Solution, iview, Field and Sub-Form to help other administrators understand your design. Include help text on any Fields that need additional explanation. Less is more, especially with Data-Driven Events (DDEs). o Every DDE is validated every time a change is made to a record or a save is made. o If there are too many DDEs, the performance will lag. o Multiple DDEs can engage at once, if they are not carefully configured. In the case of Conditional Layouts, they can cancel each other out. In the case of filters or set values, the field can be re-written. Note: To simplify the use of Conditional Layouts, Advanced Workflow (Archer versions 6.0 and later) allows for distinct layouts for individual notes. Navigation Menu (impacts for 6.x since it has been removed/modified) The Navigation Menu should display [Advanced Search/Search Records], [Add New] and [Display All/Records] links. Note the Display Setting of the Navigation Menu for the Workspace (Expanded/Collapsed/Hidden). RSA recommends the Expanded setting. The Solution Content Setting (Display All/Selected) must be set to Selected with the appropriate solutions selected to display. If the Solution Content is set to Selected, the settings for the solutions navigation menus should be set to Expanded. Configure the Navigation Menu to list the primary application first, with supporting applications listed in order of the associated workflow. This helps end users understand the workflow associated with the solution. Layout (impacts for 6.x as there are multiple layouts possible for advanced workflow) The application and sub-form layout should evenly distribute fields across both columns. Grid-based fields including cross-references, related records, sub-forms, attachments, and history logs should be grouped together at the bottom of the layout. Grid-based fields should not more than contain 4-5 columns of information. Use tab sets under the following conditions: o The application contains a logical progression of steps (i.e. field groupings) that must be completed in order. o The application contains a large set of instructions or supplemental information. Every application and sub-form should have fields organized into relevant sections, directing users quickly to the information needed. With the exception of History Log and Attachment fields, or sections that are not regularly used, sections should be expanded by default. 3

4 To ensure that page layouts and workflows are user friendly, RSA recommends that you perform tests from the end-user perspective. o Radio buttons/drop downs/popups should be used appropriately. o Editable fields should follow a logical process flow. o Required fields are on initial tabs and do not require a lot of work to save a draft. Important: Unless you have requirements, or a clear directive from the client, you should never delete or repurpose fields or applications, even when those fields or applications that are not currently used. Instead, you should inactivate and rename, or obfuscate the field. There are two significant risks to consider when delete or repurpose fields or applications: o The client may need to use those fields at a later time. This is particularly challenging when you have repurposed those fields for another use as then you have two issues; reconfiguring the original field, and configuring a second field to accommodate the repurpose elsewhere. o Implementation of future out-of-the-box functionality is much more difficult to perform for the reasons noted above. Deleting fields can impair the ability to integrate Focused Solutions and other new functionality. History Logs Every application should have a History Log field. Retention should be set on History Log fields. o Select needed fields, do not track all fields. o Do not set history for calculated text fields as a general rule. There are appropriate times to track calculated fields (e.g., the higher level status, etc.). o Do not forget to update your selections before an implementation. Failing to update selections can result in the tracking of unnecessary fields. Always make History Logs a link instead of a grid format. If cross reference / related record fields change frequently or have many references, do not set those fields to be tracked in the history log. Notifications Applications should have notifications enabled by default. Notification alerts should be periodically sent to users and should direct them to the record needing action. Calculations Calculations should be as simple as possible. Calculation order should be reviewed often. Ensure that calculated fields function as intended. For example, test all values within a calculated values list display for the appropriate condition. o Test your calculations with actual data. o Test both positive and negative conditions. o Validation in the Formula Builder only validates syntax. It does not validate the calculation itself. o Keep the Error Handling set to Display Error as much as possible; it is the only indicator you may have that a calculation is not working. o Test with live data to help you identify calculation order issues. Set calculations to As Needed calcs. Only calculations that use NOW() or TODAY() should leverage always. o Additionally always can used for troubleshooting or for calculation testing. o Be sure to return the setting to As Needed once you finish troubleshooting. 4

5 Account for NULL dates in calculations. Unaccounted NULL dates show as an error. Account for multiple cross-reference or sub-form entries when calculating across applications. o Most Recent Value or Combined Values can help. Remove calculations from inactivated fields. If you want to save the calculations for future use, copy them into the Description field. These calculations can slow down performance when saving records. Values Lists Single-select values lists with 2 values should be displayed as drop-downs or radio buttons. Single-select values lists with 2-5 values should be displayed as a drop-down. Single-select values lists with more than 5 values or multi-select values lists should be configured as a values pop-up. The use of Global Values Lists (GVLs) should be limited to use cases where a GVL is referenced multiple times within the same application. Cross-References and Sub-Forms Cross-reference fields displayed as grids should contain the related applications key field in the first column of the grid. Cross-reference grids should have a default display of 5 records for a cleaner appearance. Users can click View All to see all references. Displaying more than 5 records can slow down performance. Questionnaires Questionnaire questions should be limited. To improve performance and usability, questionnaires should be split into multiple tabs or into multiple questionnaires. Datafeeds Archer-to-Archer (A2A) feeds should run as few times as possible. Attempting to simulate realtime activities can cause the system to perform unnecessary work and can lead to confusion for end-users, as changes don t reflect until a page refreshes. For example, specifying an SLA (such 15 minutes) results in 96 executions a day compared to 288 for 5 minutes or 720 for 2 minutes. Data feeds should consume change sets rather than full collections. Use Tokens. Searching and Reporting Reports/dashboards (work queues) should drive regular user workflow. Choose Search Results formatting carefully. The column format is recommended for most reports, but you should consider which format provides the best user experience when returning search results. All global reports associated with an application or solution should be reviewed for applicability, and non-relevant reports should be hidden from end-users. Standard grid-based reports should contain less than 10 columns of data to allow for the best visual representation of the data set, and should include the key field as the first column. Solution Master Changes Avoid structure changes to core applications like adding or removing levels. Level changes can impact upgrades and packaging. 5

6 Avoid major changes to the Findings application. Changes could adversely affect Findings generation. Mail Merge Before changing a field s alias, verify that they are used in mail merges or data feeds. Changes to aliases cause you to reconfigure related mail merges and feeds. Note: Check your spelling and grammar throughout the application in your configurations and descriptions to ensure a professional impact on end-users. Usage 1. Use a supported browser with the recommended settings (compatibility, security, etc.). 2. Establish a governance program for coordinated ownership of common or shared applications. 3. Use Packaging and Mapping for synchronicity between environments. 4. Design workspaces that are effective users activities; a collection of links for actions and/or information is more valuable than 3 different views of a queue. 6

7 Use of cached reports is not recommended.support and Service Customer Support Information Customer Support Other Resources RSA Archer GRC Community on RSA Link: Our public forum, on the new RSA Link Community platform, brings together customers, prospects, consultants, RSA Archer GRC thought leaders, partners and analysts to talk about GRC as a practice, and includes product demos, GRC videos, white papers, blogs and more. Archer Customer / Partner Community on RSA Link: Our private community, is a powerful governance, risk and compliance online network that promotes collaboration among Archer customers, partners, industry analysts, and product experts. Engaging with the RSA Archer Community on RSA Link enables you to collaborate to solve problems, build best practices, establish peer connections and engage with RSA Archer GRC Thought Leaders. RSA Ready: RSA's Technology Partner Program is where 3rd parties gain access to RSA Software in order to develop an interoperability and have it documented and certified. RSA Readycertifications are posted to an online Community and supported by RSA Support. 7

8 Copyright EMC Corporation All Rights Reserved. Published in the USA. November