RAM log

Abstract

RAM log

The RAM log allows Workbench users to troubleshoot and review RAM activity within the system.

• RAM log information is stored for six months.

• When using the RAM log to troubleshoot, it is helpful to take a screen capture of your RAM trigger (rules, conditions, actions), or have the RAM trigger open in a separate browser window, to easily compare the results to the configuration. The RAM log is not always easy to read or intuitive, so being able to view the configuration at the same time can be beneficial.

• Tier 5, Power User, Tech Services, Helpdesk, and Super Users have access to the RAM log.

• At least one search field must be entered to run a search.

• Searching by one or more triggers, with one or more statuses, to research a specific trigger issue.

• Searching for a specific candidate and selecting the time that covers the candidate’s recent HR Status history.

  • By not specifying a requisition, all triggers that ran on that candidate are returned.

• Searching by a specific requisition, for triggers that are requisition-specific (not candidate specific).

  • Entering a “0” for the candidate reference number speeds up the search by limiting it to only triggers that don’t have candidate in their context.

Process

1. To open the RAM log, select Tools → Automation Manager → RAM Logs.

   

2. Select the Search Parameters:

   1. To search by One or More Triggers, enter the Trigger Information details. A specific search can be run to view all activity for a specific RAM trigger, or triggers. In addition, to help troubleshooting, the status of the trigger can be specified.

      

   2. To search by a specific candidate, enter the Candidate Information. A specific candidate can be searched to provide a list of all RAM triggers that have run for the candidate. Searching is available by First Name, Last Name, or Candidate Reference Number. In addition, a time period can be added to target specific triggers.

      

   3. To search by a specific Req, enter the Req information. A specific req can be searched to provide a list of all RAM triggers that have run for that requisition. Searching is available by Auto Req ID (example: 123BR). In addition, a time period can be selected to target specific triggers.

      

3. Select Search.

4. The RAM log results are shown in a grid, which is sorted by the most recent trigger run time. Results display in the grid for the last 6 months for RAM triggers. AM triggers do not have logs. Other columns can be sorted to identify a specific trigger instance.

    

The Raw RAM Log

Abstract

The Raw RAM Log

View Raw Log

Select View Raw Log for a trigger instance to display more details of what occurred with that trigger when it ran.

Reading the Raw Log

1. Each log starts with [“Start trigger …”]. This line indicates the trigger number, the Client ID, and when the trigger ran, not when it was triggered. The time is in US EST.

2. Selecting the light blue hyperlink displays the trigger delay, delay mechanism, and trigger mechanism.

3. This line depends on the type of trigger, but in this example, it shows the Candidate Reference Number and Req IDs (both ‘custom’ and BR/standard).

   • The log displays two lines for each rule:

     • The first line for the rule is green if all the conditions are true, or dark blue if at least one condition is not true.

     • The second line is green when the rule is true and the action was taken. Selecting the link extends and displays all actions that were taken. Each action can also be extended to see, for example, email address used in the Send Communication action.

4. This rule is the first rule in the trigger, indicated by the (1), and shows a green link for both lines, meaning all conditions were true and an action was carried out.

5. This rule shows a dark blue color for the first link because at least one condition was found to be not true. The second link for the rule is not hyperlinked because no actions were carried out.

Selecting the first Processing Rule… link displays a line for each condition.

• Green means that the condition is true.

• Orange means that the condition was not true.

Selecting the condition gives more detail. For example:

• First Condition: Looking for the Department field on the Corporate Hiring req form to = Office (Code is: Corporate).

  • The field is found (1) on the req form.

  • The field on the req equals (EQ) = Franchise and the RAM is comparing it to the condition’s option.

  • Therefore, the condition is NOT TRUE.

• Second Condition: Looking for the current HR Status to = Not Qualified (40851).

  • The HR Status is found (1).

  • The HR Status equals (EQ) = 40851.

  • Therefore, the condition is TRUE.

  • Tip: Find the HR Status ID by doing a ‘view source’ on the HR Status page of Workbench.

The second Processing Rule… link is available if all conditions are true.

By selecting the link to expand the action section, you can view what actions were successfully taken. In this example, the action was to Send the Candidate Rejection communication template to the candidate.

The log always terminates with End trigger… and the green grid. This includes the date and time when the trigger finished running.

This grid should always be included in tickets/PMRs sent to the GSC as it clearly identifies the client, environment, trigger, candidate, and requisition data.

When working with integration RAMs (RAMs configured to perform web service operations), view the XML sent to the vendor by right-clicking on the grid, then selecting View source. This provides you with more log data.

• Find the section corresponding to the XML request and response (these are embedded within an <h5> tag on the left side).

• For both the request and response XML, two versions are shown. The second one is the actual XML with data values present sent to the external system (values are based on the mapping provided).

Multiple Start and End Trigger Sections

If the trigger ran multiple times the [Start trigger…] and [End trigger…] would be repeated each time that the trigger ran in chronological order.

• The last run is found at the end of the log.

• Example shows that the trigger ran twice on 3/31 and then again on 5/06:

“Truncate to the most recent” Message

The message [Log has been truncate to the most recent 250 000] indicates a complex trigger that has run multiple times, as there are too many rules, conditions, or actions, or the pull trigger is misconfigured. If this happens, create a PMR. Most likely, the trigger is not configured correctly, which can have a negative impact on the system. Only the most recent ran log is available. Always start from the end.

Conditions

The color coding, green for true versus orange for false, for the conditions should be enough to identify the condition that was true or not, at the time the trigger ran. If a condition is true now, but was not true at the time the trigger ran, it is most likely due to a change that happened after the trigger ran, such as an HR Status update, a form update, or a change to the trigger rather than an issue in RAM. Refer to the RAM trigger’s start date, end date, and time stamp, and compare that to date and time stamps viewable in BrassRing to see whether the actions took place after the RAM trigger ran.

Example shown: RAM checking a field that doesn’t exist.

[“DataSet: Empty”] means that no value was found for the field non compete. Either the form, or the field on the form, does not exist at the time the trigger ran. If the field exists on the form, ensure it is the field on the same req template that is included in the trigger.

RAM Log Actions and Statuses

Abstract

RAM Log Actions and Statuses

RAM Log Actions

Two actions are available after the RAM log is run.

1. Rerun selected trigger(s): Allows the user to select a specific instance, and rerun the trigger. This is typically used if a change is made in BrassRing, and the user wants the RAM trigger to be rerun without having to undo and redo a status, or remove or add a form.

2. Refresh search results: Allows the user to get the most up-to-date list of RAM triggers that were run. This is used when you are waiting for a RAM to run, or when you have been the page for an extended period and would like the most recent list.

RAM Log Statuses

The RAM log has 25 statuses that are broken into four categories:

1. Success

2. Error

3. Warning

4. Pending

Success Statuses

Success Statuses:

• Success with other action(s) - At least one action was taken and it was not a final action, such as an HR Status update, exit, run another trigger, or instance.

• Success with exit action(s) - One of the following actions (HR Status update, exit, run another trigger or instance) were taken.

• Success with no action - No rule was true so no action was taken. If this happens often, it might be due to the use of an incorrect trigger mechanism.

  • No qualified req found to update HR status - Trigger is setup to update the HR status in other reqs but the candidate was not found to be in any other reqs meeting the criteria.

• Duplicate Trigger Skipped - Multiple events have triggered the same trigger multiple times for the same candidate, or requisition. Only one is processed, and the others would be skipped. This is usually due to misconfiguration. For example, by using across candidate or requisition trigger contexts. If this happens often, create a PMR. Make sure that multiple triggers are running parallel that take the same action. Many skipped triggers indicate issue with the design of the trigger.

• Most triggers should complete with either Success with exit action(s) or Success with other actions.

• If the client as many triggers with the status of Success with no action or Duplicate Trigger Skipped, review these triggers. They create unnecessary workload, and might delay other triggers. It might also be due to incorrectly configured conditions.

Error Statuses

Error statuses indicate an issue with the configuration, data, specific workflow, or a system issue.

• When one of these errors occurs, check whether the error is specific to a trigger, candidate, requisition, or any combination.

• The RAM log can be used to isolate where the error is occurring.

• If the error happens for a specific candidate, compare the candidate’s Talent Record, HR status, and any forms that are used by the trigger, with other candidates that didn’t result in the error.

• If the RAM trigger results in an error status that requires a PMR, allow engineering time to review and provide more detailed information before contacting the client with a status.

Error Statuses:

• Error while processing - Unexpected error. Create a PMR.

• Error writing log files - Problem while saving log. This is uncommon. Create a PMR.

• Unexpected error(s) after processing - Very uncommon. Create a PMR.

• Unexpected error(s) before processing - Very uncommon. Create a PMR.

• Error calling WebService - Error calling an external Webservice. This is typically on the client or vendor side. The client/vendor needs to make sure that their Webservice is up and running.

• Error after all retries - Final error after all six automatic retries have failed.

• Error setting HRstatus - Error trying to update an HR Status. Make sure that this update is possible according to client configuration and requisition status. Check Client Settings “RAM - Allow HR status update for closed reqs” or “ByPass ClosedLogic when Updating HRStatus in RAM”.

• Error sending communication - Unexpected Error while creating the communication. Try to send the same communication from BrassRing manually. Common errors are: Missing token, incorrect communication template. If it is not a data issue, create a PMR.

• Error with WOTC - Might be caused by an incorrectly configured WOTC trigger. Make sure that the fields are mapped correctly in the pre-configuration. If the error occurs on a few candidates, then review the data on the candidate form that the trigger used for this specific candidate.

• Error with form Insert/Update - Make sure that the constraint on various fields allows copying and old form, and that there were no old options that have since been inactivated. The date field must allow dates from previous years, otherwise copying from previous years fails.

• Copy Form failed - Make sure that the constraint on various fields allows coping an old form and that there were no old options that have since been inactivated. The date field must allow dates from previous years, otherwise copying from previous years fails.

• Candidate does not exist. - Something happened during the candidate application or import process. If it happens regularly, create a support case.

• Export Error - Make sure that the export is set up correctly and works outside RAM.

• Invalid Delay - If the delay comes from a form field, make sure that the field as a valid value.

Errors will usually be found at the end of the log after selecting the last rule link.

When an error is received from another application, RAM displays that error. This example error is due to server misconfiguration.

Warning Statuses

Warning statuses are expected errors based on client configuration or setup. Clients should review them during Staging testing and add necessary conditions or make necessary configuration changes to prevent them.

Warning Statuses:

• WOTC warning (candidate already hired) - WOTC expected error candidate already hired.

• Warning setting HRStatus - Error that occurs if the tracking logic does not allow the update or req close. Check to ensure that the RAM - Allow HR Status Update for closed & cancelled reqs client setting is enabled.

  • If your RAM trigger has a Trigger Mechanism of Req Cancelled and you are seeing this warning status, you also have to enable the RAM - Allow HR status update to trigger candidate export integrations client setting. Client Settings can only be configured by an Infinite Representative. Contact your Infinite representative to have this setting enabled if needed.

• Warning sending communication - Error when sending the communication. The communication was created successfully but the sending feature is failing. Review the RAM log, as this might be caused by an invalid or missing email.

• Export warning - Make sure that the export is set up correctly and works outside RAM.

• Candidate was archived - Candidate has been archived before the trigger ran.

• Candidate was moved - Candidate has moved to another requisition.

• Candidate was deleted - Candidate was deleted/purged from that requisition.

• Candidate was not filed - Form as created for the requisition that the candidate was never filed to.

Pending Statuses

Pending Statuses are intermediate statuses, not final statuses. They should be ignored by client except if:

• The trigger, which doesn’t have a delay, is in progress for more than 2 hours. Create a PMR to rectify this.

• Suddenly the status Pending retry after error(s) starts to show for multiple. A common issue is when the trigger contains a client integration and that integration no longer works. Create a PMR after verifying that the issue is not on the client side.

Pending Statuses:

• Pending retry after error(s) - Error occurred, automatic retry is pending. No action needs to be taken. The RAM automatically retries after 1 minute, 1 hour, 6 hours, 24 hours, and 48 hours. The last attempt occurs after 79 hours and 1 minute from the initial time the trigger ran.

• Pending(not queued yet)

• In progress - Specific to delay processing where the trigger has a delay and shows this status, until the delay is reached, and the trigger runs. This is not available with other delay triggers. Another possibility is the trigger is being delayed because of backlog. (Rare)