Business Scenario

Security Administration:

Security administration is the maintenance of user profiles, roles, resources, and access. It starts with the concept of a “resource”. A resource is a form (screen), a user interface control (screen element the user can interact with, such as a field or tab) on a screen, or an action the user can take on a screen (generally a button the user can click). For a resource to be meaningful, the element (or elements) it defines has to be developed in the system. For example, nothing prevents you from creating a resource for a screen called “Test Screen”, but assigning that resource won’t actually do anything if “Test Screen” isn’t really part of the system. Please refer to development training for creating user interface elements and linking them to resource levels.

Please also note that there is not necessarily a one-to-one relationship of resources to UI elements. It is the exception, rather than the rule, for each element on the screen to have its own security level; usually screen elements have the same level as the screen itself. It is also possible, although not considered best practice, to use resources for multiple screens.

The important resource properties are:

•      Resource ID: Programmatic ID number used during development to link a screen or screen element to its corresponding resource record. Once the resource is linked to one or more UI elements, you’ll be able to view their programmatic ID(s) on the resource record, as well.

•      Resource Description: Plain text name for the resource. This is how SUITS refers to the resource on other records, such as the role(s) it’s assigned to.

•      Type: Identifies the resource as an Action, Form, or UI Control.

A group of resources representing all the screens and screen elements a specific kind of user should have access to; and, for each resource, the access that user should have, is called a “role”. Security access levels have the following options:

•      None: The user with this role has no access to the resource.

•      Read: The user with this role can only view the resource.

•      Modify: The user with this role can edit existing data associated with the resource, but cannot create new data or delete existing data.

•      New: The user with this role can edit existing data and create new data, but cannot delete existing data.

•      Execute: The user with this role can use the resource to accomplish some business goal. For example, if the resource is a button which submits data for approval, the user can click the button to submit that data.

Each level of access includes all preceding levels. For example, a role with New access to a resource also has Modify and Read access folded in.

The other important role properties are:

•      Role ID: Programmatic ID number SUITS automatically assigns to identify the role.

•      Role Description: Plain text name for the role. This is how SUITS refers to the roles on other records, such as the user(s) it’s assigned to.

•      Role Type: Identifies the type of user the group of resources and access levels which comprise the role are intended for. Your options are: Employer, Internal, Third Party Administrator, or All.

•      Role Category: Identifies the category the role falls within.  Your options are: Case Management, Counselling, Reporting, and Workflow Manager.

A group of roles representing all of the resource groups a specific person should have access to is called a “user”. Each user also contains a number of other properties, including the level of activity SUITS includes in its sessions records, the user’s landing page upon logging into SUITS, the settings which control which workflow activities the user can access, and so on.

Audit Log:

The audit log records the data individual users create, edit, and delete; as long as that data is configured to be part of the audit log. This is a development property that is exclusively back end, on the level of the database table which contains the data. Any database table can be configured to be included in the audit log: business data, workflow data, systems administration data, etc.

Any user may also view limited audit information for any record (maintenance screen) by navigating to that record and checking the bottom of the screen. While the audit log shows specific data value changes, the screen audit only displays the user who created the record, the creation timestamp, the user who most recently updated the record, and the update timestamp.

Job Schedules

A job schedule, also called a batch, is a collection of steps the system executes in sequence to accomplish a business goal, such as processing a file or generating a report. The system code uses a batch handler to run all batch jobs. The batch handler contains instructions for each step of running the job. It refers to the steps by their names and IDs, which must be configured on the job schedule in SUITS. If the batch handler has a new batch, you must create a job schedule in SUITS so the batch handler has records to refer to.

Besides the schedule and step IDs, job schedules define what triggers the system to execute the job (either an event such as the system detecting a received file or a user clicking a button; or a date and time based on a schedule type), whether the system will run the job when triggered, the job’s priority level when the system is running multiple jobs, whether an instance of the job running can or cannot be canceled before it finishes, email address(es) for notifications about the job, and any other notes describing how the job functions.

An individual job step consists of its programmatic ID and name, plus properties defining whether the system will include that step when it runs the job, the order it runs in relative to the job’s other steps, any dependency it has on other steps, the percentage or number of records at which the step records processing in the process log, and any parameters a user can enter.

Parameters:

A parameter is a defined value the system uses to select the data it will process. An example of a parameter is a fiscal year: the system may need the user to enter the fiscal year the user wants the system to use to determine which data will be included in the ensuing report/file.

If the parameter value is the result of the system code executing some logic or retrieving system data, then the step parameter will be entered as null or 0. The system will automatically assign the parameter when it executes the job and display the assigned value on the job’s instance record for that step.

If the parameter value is determined by the user outside of any system logic or data, then the user manually enters the desired value on the step before the job runs. The job instance record for that step will display what the user entered before the job ran. Please note that requiring a business user to manually enter a batch parameter on the step record itself is not considered best practice.

If a step record does not have any user parameters, any values the system needs to select data will have to come from the code itself, according to some calculation or business rule. For example, the job step may always use the current fiscal year to select data; so the code simply directs the step to use whatever the current fiscal year is. Please note that in such a case, you cannot know anything about that parameter from the step or step instance record, including that it even exists.

Post-Execution:

Regardless of the job schedule’s Frequency Type or how it was initially triggered to run, you can view its progress from the second it starts to any time after by opening its instance. An instance is an individual record of a job schedule’s execution, with information about the status, success or failure of each individual step and the job as a whole. An instance does not contain any information about the actual records or data the job affected (beyond a count). Depending on the job schedule’s other properties, you may be able to cancel a running instance or restart an instance that has been canceled.

System Management:

System management consists mostly of viewing and maintaining the following properties:

•      System Availability: This is editable. It determines the type of user who can access the system and user type read/write permissions.

•      System Date: This is editable. The date the system thinks it is for the purposes of processing data is dependent on a back end development property. However, this field allows you to override that date if necessary to execute a date-dependent process, as long as the region is not Production.

•      Base Directory: This is editable. It is the location of all the application’s file folders, or system paths. Never change this unless the files have moved.

This functionality has one other part in non-production regions: refreshing the servers. If you refresh the servers, you affect three different kinds of application logic:

•      The files which comprise the user interface (XML files). This is called the “metadata cache”.

•      The files which comprise the business logic (validation rules, logical rules, etc.) This is called the “business tier”.

•      The data which represents system constants (but not the business data, such as member information). This is called the “database cache”.

A business user does not have access to the first two kinds of logic, but does have access to the system constants (codes and messages). Therefore, every time you update a system constant, you must refresh the servers so the update will be available in the application.

System Paths:

In system management, the Base Directory is the location of all the folders the system uses for business processes (storage of data files during file processing, communication templates, etc.). The system needs to know the specific location of each folder it uses beyond just the base path. The relative location of each specific folder is its system path.

You must create a new system path whenever the system needs to refer to a folder for which it does not yet have a system path. Update a system path if an existing business process changes the folder it uses.

Codes:

Codes define constants the system uses to populate data it needs for business processes. The functionality available in the screens which contain code information reflects the database structure the system uses to manage codes. Specifically, the system uses two database tables for codes: the code ID table and the code value table. The code ID table assigns numeric IDs to categories of system constants, such as “countries” or “states”. The code value table contains all the values for every code ID, referenced by ID, such as “United States” and “California”. The following is a simple diagram:

Code ID Table:

Code Value Table:

Whenever the system needs to refer to a country, it can just check the “1”, or “Countries” code group. Whenever it needs to refer to a state or province, it can check the “2”, or “States/Provinces” code group. Keeping system constants in the same place and sorting by code group improves performance and simplifies the code. The alternative would be to have a table for all the countries and a separate table for all the states/provinces. This would divide system constants into hundreds or thousands of tables instead of only two, and the code would have to query each table individually.

Please note that updating code values has no effect on the logic execution itself. If you add code values or change existing ones, a developer has to edit the logic so the system will use the codes appropriately.

Please also note that you should never create code records for benefit plans. Plans cannot be simple system constants; they require more security and complexity. They are a special kind of data and are managed elsewhere.

System Messages:

System messages, as defined by message records in SUITS, are lines of text which give the user information about the screen they’re on, the data on the screen, what to do next, and the result of user action. They appear where they are configured during development, which is nearly always either the top or the bottom of the screen. Their color is also a development property, but generally system messages at the top of the screen are red. These red system messages are hard errors which prevent the system from saving or otherwise changing the data.

Besides the error messages defined by the message records, the system can display informative white text at the top of the screen. For example, if a user searches for a record, the system tells the user how many records it found. This is configured elsewhere in development and has nothing to do with system message records.

Any time the system displays a message that has an ID, it is a message defined in the system messages. Please note that it is possible (although not best practice) to configure a hard error message in the development files that does not have a corresponding message record in the system.

Messages can also contain external instructions (if they are used in a system portal) or internal instructions (if they are used in the internal system), or both. For soft errors, these instructions will also display alongside the system message if configured to do so.

Create or edit messages as the system logic dictates. If the code has a new kind of soft error rule, it requires a corresponding soft error message so the system knows how to treat a record which contains that error. If you want to change how the system treats an existing error, change that error’s severity level.