4/5

1 Argus Safety Service Overview

The Argus Safety Services are a suite of processes that run to reduce the load on the front end experienced by perform complex process in the background. These processes that performing several tasks in the background. Argus Safety Service Configuration provides an interface to configure these processes.

The following table describes each of the major steps that should be followed to configure Argus Safety Service:

Task	Description
Understanding Tasks	Ensure that Argus Safety has been configured so that the Argus Safety Service processes can be configured. Refer to the Argus Console User Guide for details on configuring Argus Safety.
Configuring Argus Safety Process	Specify details for scheduling Argus Safety Service processes.

Argus Safety Service in a Multi-tenant environment

Each AG service procesess the data for all enterprises. It does not need to be segregated by enterprises as it is not meant for the end users and is maintained by the CRO Administrator or Hosting provider.

While performing any single task at a time, Argus Safety service will not inter-mix data from multiple enterprises.

The user configured to run any AG Service task must belong to all enterprises as these tasks have to process records for all the enterprises.

Understanding the User Interface

You can create Argus Safety processes configure existing processes from the Argus Process dialog box.

Argus Process Dialog Box Fields and Field Descriptions

Item	Description
Name	Enter the name of the Argus Safety Process.
Process	Browse to the Argus Safety Service Installation folder and select the AGProc.exe file.
Task	Select the task to run that is associated with the Name entered in the first field.
Start Time	Enter the Initial Start Time for the Process. After the initial starting, the process will follow the Interval set in the next field. If Start Time is not selected, the process will begin immediately after starting the service.
Interval	Enter the frequency at which the process will be executed.
Suspend	If a process is running for a period that is longer than what is specified in this field and the memory consumption of the process is below the Low Water Mark specified in the next field, then the process will be terminated. Default for 5 Minutes is the ideal setting and should not be changed.
Low Water Mark	The Low Water Mark setting works with the Suspend field above. The Default setting of 200 is ideal and should not be changed.
Database	Enter the database name.
User Name	Enter in the Argus Safety Service User name that the process will connect to the system as. These users should be configured before using this utility. Each Process requires its own user configured to run.
Password	Enter the password that has been configured for the user entered above.
Confirm	Re-enter the password that has been configured for the user.
Failure Email	If a process fails, an email is sent to the address specified in this field.
Fax (Note: This section is enabled only if Fax or Fax Status is selected in the Task list)
Server	Enter the Fax Server name that the Fax Process will be using to submit faxes with. This field will only be enabled if the Task selected is either FAX or FAX STATUS.
Notify Email	Enter the Email Address of the Administrator that will receive the email in the event that Argus Safety Service can not access the Fax Server.
User Name	Enter in User name that the fax will connect to the system as.
Password	Enter the password that has been configured for the user entered above.

Understanding Tasks

The Task list in the Argus Process dialog lists the different items for which processes can be created.

Task Descriptions

Item	Description
Auto Accept E2B Reports	When ESM Service receives incoming E2B reports and the Argus Console for the electronic recipient is configured to auto accept in Reporting Destination with the AGService Process, then AGService auto accepts the E2B reports. The process creates a case for Initial reports or updates the case for follow-up reports received in a Queue. After auto accept, the system moves the reports to "E2B Processed" screen and ESM Service generates an Acknowledgment.
Audit Log Export	Argus Safety allows the export of Audit Data to a table in a format that is readable by a user. This process exports up to 2000 cases at a time. After 2000 cases have been exported, the process shuts down and starts again at the next scheduled interval.
Audit Log Update	Argus Safety allows auditing of data which are updated through database scripts. The Audit Log Update process updates the Audit Log, based on the item stored in the queue. This process audits up to 500 audits in a row. After 500 Audits have been completed, the process shuts down and starts again at the next scheduled interval.
AutoSignal	Argus Safety allows the configuration of Signals. Signals can be used to detect events that can be configured using Advanced Conditions. Argus Safety Service will automatically check for triggered events and notify a selected user of the event.
Batch Report Generation	The Batch Report Generation process eliminates the process of a user having to manually generate a report during a case workflow. Rules can be setup in Argus to have reports automatically generated on a scheduled basis. Using this process speeds up the day-to-day tasks for the end user by moving the Report Generation Load to the Argus Safety Server. This process executes batch jobs in the ascending order of Due Date of the report (Earliest Due First). It processes 10,000 reports in a day at a minimum. For details about the Batch Report Generation process, see Batch Report Generation Process.
Batch Memorized Reports	The Batch Memorized Reports process allows users to have System Reports such as Case Listing Reports and Case Data Analysis Reports automatically-generated, based on a pre-configured report.
Batch Periodic Reports	The Batch Periodic Reports process removes the need to remember to schedule, generate and submit IND, NDA and PSUR Reports. Periodic Reports can be automatically scheduled and generated on a schedule configured based on the License Award Date. Using this process also speeds up day to day tasks for the end user by moving the Report Generation Load to the Argus Safety Server and off the Web Server. This process executes batch jobs in the ascending order of Due Date of the report (Earliest Due First). It processes 10,000 reports in a day at a minimum.
Batch Report Case	Batch Report Case allows users to run reports on a scheduled date.
Bulk Report Print	Prints the reports from a particular enterprise to the printer configured for that site in Console for that enterprise.
Bulk Report Transmit E2B	When a user transmits an E2B Report from "Bulk Reporting" screen, this AGService generates the E2B Report, if not previously generated, and transmits the report to ESM Service. The ESM Service creates a report in the outgoing folder, depending on the configuration.
Bulk Report Transmit Email	Argus Safety supports Bulk Submission of reports for e-mailing. The Bulk Report Transmit Email Process will automatically generate, submit (if the report has been marked for submission) and e-mail reports based on the e-mail address configured for the Report Submission Authority. Using this process speeds up day-to-day tasks for the end user by moving the Report Generation and Emailing Load to the Argus Safety Server. Argus Safety Web requires this to process Emails. This process e-mails up to 1000 reports in a row. After 1000 e-mails have been sent, the process shuts down and start again at the next scheduled interval. This process executes batch jobs in the ascending order of Due Date of the report (Earliest Due First). It processes 10,000 reports in a day at a minimum.
Bulk Report Transmit Fax Note: If E2B Reports are going to be transmitted, the Bulk Report Transmit Fax process must be running.	Argus Safety supports Bulk Submission of reports for faxing. The Bulk Report Transmit Fax Process will automatically generate reports for Fax Submission via Fax. Argus Safety Web requires this process to have the ability to fax. This process faxes up to 1000 reports in a row. After 1000 faxes have been completed, the process shuts down and starts again at the next scheduled interval. This process executes batch jobs in the ascending order of Due Date of the report (Earliest Due First).The process processes 10,000 reports in a day at a minimum.
Documentum Report Push	Refer to Argus Console for storing submitted expedited and periodic reports into Documentum.
Dossier Notification	After a PSUR report is generated and if Dossier is enabled, this process sends e-mails to all users who are members of groups with assigned roles for periodic reports.
Fax	The Fax Process will automatically transmit fax reports processed by the Bulk Report Transmit Fax Process for Submission.
Fax Status	The Fax Status Process will continuously check for the status of the Fax Submission to update Argus Information. This process is required to be running if the Bulk Report Transmit Fax Process is enabled.
Forced Report	When forced reporting is configured, this AG Service sends out forced expedited reports, based on configured reporting rules. This task has a dependency on the Scheduling Check task, so both must be configured.
General Email	This process sends all the Workflow Routing emails which can be configured within the Workflow Configuration. It also sends all the Investigator Alert emails which can be configured within the Study Configuration as defined in the Investigator Group configuration.
General Fax	This service is used when a fax service is configured to transmit faxes. It transmits pending faxes in the queue of faxes that are waiting to be sent.
Letter Generation	When letters are configured to be sent based on the case data and configured criteria, this service auto generates letters from cases where the Contact Date has been reached.
Local Labeling Report Scheduling	The Local Labeling Report Scheduling process automatically schedules reports based on the Regulatory Rules configured in Argus for licenses that are marked as processed from the Local Labeling dialog. Report Scheduling occurs in the order of the Case Master Follow up Date or the Initial Receipt Date if Follow up is null. This is in ascending order of the Aware Date of the case.
Priority	The Priority Process re-assesses all case priorities based on the Priority rule configuration in Argus. Using this process prevents cases from being reported on late by escalating the priority of the case which is visible by the users on the Argus Worklist, Case Form and other areas. In addition to raising priority, an escalation email will be sent to the supervisor of the group if a case is not routed to the next workflow state within a specified amount of time configured in the Workflow Rules.
Report Scheduling	The Report Scheduling process automatically schedules reports based on Regulatory Rules configured in Argus for new cases. In addition, cases requiring follow-up reports are also evaluated. Priority for new cases entered into the system is assessed from the Report Scheduling Process. After the Initial Assessment, the PRIORITY process will reassess the priority based on changes made to the case if the process is running.
Scheduling Check	Argus Safety will allow forecasting of reports that may be due within a specified amount of time for cases that have not been locked and do not have reports scheduled.

Note:

When Argus Safety Service sends an email to the local email client or print job to Adobe Acrobat, it marks the report as "Success". If the email client fails to send the email to the Server or the OS fails to print the report to the printer due to network issues or configuration issues outside of Argus, the status will not be changed to "FAILED".

It is prudent to add a manual process to confirm that the email client and print queue outside Argus Safety Service are functioning on an on-going basis.

Batch Report Generation Process

Parallel processing has been introduced into the Batch Report Generation AG Process to enable its improved performance.

This has been made possible by introducing a new AG process called BATCH REPORT GENERATION WORKER.

The Batch Generation AG Service process has been split into two separate processes:

1. BATCH REPORT GENERATION

2. BATCH REPORT GENERATION WORKER

Both the above processes need to be configured to generate Batch Reports.

Note:

The configuration for BATCH REPORT GENERATION remains the same as is.

In addition to the above process, you need to now configure the new BATCH REPORT GENERATION WORKER process as well.

Multiple instances of the new BATCH REPORT GENERATION WORKER process must be configured either on the same AGService box, or on multiple AG service boxes, to achieve better performance.

If multiple instances are configured, each process of type "BATCH REPORT GENERATION WORKER" should be configured with a different AG Service user.

Details

The The BATCH REPORT GENERATION process will populate the reports (Expedited Reports only) that need to be processed by the BATCH REPORT GENERATION WORKER in a new table BATCH_GENERATION_QUEUE.

The Report IDs from CMN_REG_REPORTS are used to populate this new table. The status column in this table indicates to the batch report generation and worker processes about how to process the corresponding reports.

It will have one of the following values:

Value: Status	Denotes that..
0: Pending	The record has been populated by the Batch Report Generation process but has not yet been picked up by the Worker process.
1: Processing	The record has been picked up by a worker process for generation.
2: Completed	The report has been successfully generated.
3: Failed	The report generation failed.

If the report generation fails, another record for the same Report ID is inserted in the queue table during the next run of the BATCH REPORT GENERATION process so that the Report generation is tried again.

At any point of time, there will not be more than two records in the queue table with the same REG_REPORT_ID.

If a record in the queue table remains in Status "1" for more than 2 hours, then the Status is marked as "3" during the next run of BATCH REPORT GENERATION process.

The records with Status "2" get removed in the next run of the BATCH REPORT GENERATION process.

The records with Status "3" get retried once by the process.

After that, the report is not retried for 8 hours and will get removed after the 8 hour window.

Note that the failed records are kept for 8 hours in order to prevent the same record, which may have failed due to configuration or data issues, being retried continuously.

Once the failed records are cleared after 8 hours, the report will be retried for generation. The 8 hour cycle will repeat indefinitely until the report generates successfully or until the report is deleted.

For expedited reports that are set to generate on DLP, when the BATCH REPORT GENERATION process runs and sees that there are still DLP Reports yet to be picked by a worker process or is still being generated, it will exit without adding any more DLP reports to the queue.

Once all the DLP reports (RUN_ON_DLP = 1) are processed (i.e., have STATUS = 2 or 3), the BATCH REPORT GENERATION process will insert more DLP reports to the queue table.

Note:

The logs of Success/Failed count for the Batch Generation process are now distributed across multiple processes. Getting a cumulative count is not possible. Customers need to check the BATCH_GENERATION_QUEUE table to see if there are failed records which have failed consistently.

The following table lists the structure of the queue table:

Batch_Generation_Queue
Column Name	Data Type	Nullable	Primary Key	Comments
ID	NUMBER	No	1	This is the Primary Key of the table, and the values come from the sequence S_BATCH_GENERATION_QUEUE.
BATCH_ID	NUMBER	No		This column holds the value of BATCH_ID which comes from CFG_REPORT_SCHEDULE.ID
PROCESSING_USER_ID	NUMBER	No		This column holds the value of the AGService User ID of the process which picks up this record for processing.
STATUS	NUMBER	Yes		This column can hold the following values: 0:Pending, 1: Processing, 2: Completed, 3: Failed.
REG_REPORT_ID	NUMBER	No		The data for this column comes from CMN_REG_REPORTS.REG_REPORT_ID
REPORT_FORM_ID	NUMBER	Yes		The data for this column comes from CMN_REG_REPORTS.REPORT_FORM_ID
SESSION_USER_ID	NUMBER	Yes		For Non-DLP Reports, the value for this column is the AGService User ID. For DLP Reports, it is the Lot User ID.
STATE_ID	NUMBER	Yes		The data for this column comes from CMN_REG_REPORTS.STATE_ID
LAST_PROCESSING_TIME	DATE	Yes		The time at which the record was last picked up for processing.
RUN_ON_DLP	NUMBER	Yes		The value of 1 means the report generation should run on DLP. If not, the value should be 0.
ERROR_TEXT	VARCHAR2 (4000 CHAR)	Yes		The worker process generates the reports and if it fails, it updates the error text (if any). However, for E2B reports, the worker process just delegates to PDP for generation. The PDP generates the reports asynchronously. The worker process does not know whether the report generation has been successful. Hence, it sets the error_text as "Success value not available", and leaves the record there itself.

Configuration

Some of the parameters described above (such as the 8 hour cycle, the number of times the failed reports get retried, etc.) can be controlled through settings in agservice.ini.

More information can be found in the Default values that have been listed below:

[Batch Generation Configuration]

Max Retry Attempts = 1

This is the number of times that a given reg_report_id gets added in the queue in a given 8 hour slot. It gets added only if the first attempt results in a failure (status = 3).

The above setting indicates that if a report fails during generation, another record for the same report id is added to the queue table for the same reg_report_id, inspite of the failed record still being there in the queue (with status = 3).

This enables the report generation to be retried. If the second attempt also fails, then that report is not added to the queue again, until the queue is cleared (which happens once in 8 hours).

[Batch Generation Configuration]

Max Failed After Minutes = 120

This value is used to identify crashed reports. If a report in the queue is still in status 1 (which means "in processing") even after so many minutes, it means that the EXE would have crashed.

Configure this value to the maximum number of minutes that a report generation would take in your environment, plus 1.

[Batch Generation Configuration]

Clear Failed Records After Hours = 8

Failed reports are not inserted multiple times (for more than the configured number of retries) as long as they remain in the queue table (with status 3).

However, these records are automatically deleted after 8 hours. This is done to enable retrying the failed records again.

In the duration of 8 hours, there is a possibility that users would have corrected the case data and the reports might succeed now.

Set this value to a realistic number, as applicable.

If you set the value to an unrealistic number, in case of any report failures because of data problem, the AG Service Process continues attempting the generation of the same report again and again, thus blocking other newer reports from getting generated.

[Batch Generation Configuration]

Max Iterations = 10

This is the number of reports that a worker process tries to generate in a single run. When the worker process gets instantiated, it locks one record at a time from the queue table, and starts processing it.

Some of the reports may fail, while the others may succeed. After processing the configured number of reports (default 10), the process exits.

The next instance of the worker process comes up after the time interval that has been configured in the AGConfig utility.

Configure the above value to a higher number if the process has enough speed to generate more number of reports in the time duration before the next instance of the process starts.

You must also ensure that you verify when the agproc.exe is using maximum memory and becoming slow.

If you find that the EXE would consume a lot of memory and might slow down by the time it generates 20 reports, then configure the number to something smaller.

Whatever the configured number is, note down how much time it is taking to process so many records, and configure the frequency of that process to start another instance soon, after those many seconds/minutes.