Messaging and Scheduled Tasks

 

Jump to:

Overview
Configuring the Messaging and Scheduled Tasks Utility
Emailing a Report
Send a Regular Email
Run a Summary
Save Application Output to Server
Send an SMS Text Message
Call a Maintainer Application
Merge Data to PDF and Save to Server
Merge Data to PDF and Send Via Email
Built-in Date Parameters
Executing Task Groups
Promoting to Production

Overview

The Messaging and Scheduled Task Utility allows developers to automate server side tasks. These tasks can be simply running an application in the background or invoking an email message. Tasks can be scheduled to run on a regular basis or triggered after a specific action mode within a maintainer web form. Common tasks include: Scheduling daily reports to be emailed, scheduling a series of summaries to be ran over night, and triggering a notification email after a record has been added/updated in a table.

Creating Tasks Groups

All tasks live inside of a task group and you can have multiple tasks inside of a task group. When you call a task, you are actually calling the entire task group to execute the individual tasks in the order they are sequenced. You cannot change the name of the task group after saving. However, you can change the description of the task group.

When you create a new task, you are able to add the current task to an existing task group or create a new task group on the fly. You are also able to assign a sequence number for the task to be executed in a specific order when the task group is called.

There is also the option to put Task Groups into Test Mode. When creating or editing a task group check the Enable Test Mode box to have all the e-mails generated by that task group sent to a specified e-mail address. When the task group is ready for production, simply uncheck the box. Task Groups that have Test Mode enabled will appear bold and in red on the Messaging and Scheduled Tasks page.

Message Types

Email a Report

Target Application

• Select Report: Select the dictionary and report application that you wish to use in your task.
• Additional Parameters: Additional parameters can be passed through the URL to filter the report or control the report behavior, such as choosing subtotal levels. Using the runtime parameter listings from the report may be helpful.
• Map Fields to Report: Only used if calling your task from a maintainer. With this option, you are able to map any fields from the maintainer to the runtime record selections of your report. If not calling this task from a maintainer, this option can be ignored.
• Send as Attachment: Choose to embed the report in the body of the email message or to send as an attachment.
• Output Format: Choose the format you would like to output your report with.
• Filename: Only used if sending the report as an attachment. File extension is required when naming file (.pdf, .xlsx, .txt, etc). If passing any parameters to the report via the additional parameters box or mapping fields, you can use these parameters in the filename as well. For example, if mapping CUSNO from a maintainer to the R001 (first runtime record selection) of the report, you can use 'Report_${R001}.xlsx' as the filename. You may also use built in variables to pull current timestamp or date when the task is ran. Use ${timestamp} or ${datestamp} for these respectively.

Recipients

• Send one Report for all recipients: Selecting this option will run the report one time and deliver the same report in the same email to all recipients (hardcoded or from a distribution list). For example, if there are five recipients, the report will run once and all five addresses will get the same email and report.
• Send one Report per recipients: Selecting this option will run and deliver the report separately for each recipient found (hardcoded or from a distribution list). For example, if there are five recipients, the report will run once and send the email to the first recipient. Then the report will run again and be delivered to the second recipient. This will continue until all recipients have been sent an email.
• Send Report to address from web form: This option can only be used if invoking your task from a maintainer. Enter the field from the maintainer that will hold the email address to deliver the email to as well as the optional CC email address field name.
• Retrieve List of Addresses from Database Table?: This option allows you to use a Distribution List Retrieval to send your emails. Select the dictionary where the Distribution List Retrieval lives and the Retrieval application itself. Any additional parameters you wish to pass to filter retrieval results can be entered here as well.
• Filter Distribution List using Maintainer Form Input: If a Distribution List is selected and you are triggering this task from a maintainer, you are able to filter the distribution list dynamically by mapping fields from the maintainer to the Distribution List Retrieval. For example, if you have a customer order form maintainer triggering a task group, you can map CUSNO (customer number) from the maintainer to filter the Distribution List's records to only return emails for their customer number. This is a dynamic way to send emails from a maintainer.
• Filter Report using Distribution List: If using a distribution list, you can filter the target application report by mapping fields from the Distribution List Retrieval to the report runtime record selections. For example, you can map CUSNO (customer number) from the distribution list to a runtime record selection for CUSNO and when using the 'Send on Report per recipients' option, send each customer their own report data.
• Additional Addresses: Enter any hardcoded email addresses here that you wish to always receive an email. Multiple addresses may be added separated by a comma.

Email Info

• Sender: This will be the 'from' address when the recipient receives their email. This needs to be a working email address. If left blank, the sender address will pull from the configuration file.
• Message Subject: Controls the subject of the email. If passing any parameters to the report via the additional parameters box or mapping fields, you can use these parameters in the filename as well. For example, if mapping CUSNO from a maintainer to the R001 (first runtime record selection) of the report, you can use 'Report for ${R001}' as the subject line. You may also use built in variables to pull current timestamp or date when the task is ran. Use ${timestamp} or ${datestamp} for these respectively.
• Message: Hardcode any text to appear in the body of the email. For example, "Thank you for the order."
• Attachments: List the filenames (included file extension) of any static attachments that will always be attached to the email. These files need to be stored on the m-Power server in /mrcjava/job_streams/attachments. Multiple files can be listed separated by a comma.

Review

• Review: Overview of all options that make up your task. A great tool for troubleshooting tasks.

Send a Regular Email

Target Application

• Target Application: Select the dictionary and application that you wish to use in your task. You can use a Retrieval or Report for this task type.
• Additional Parameters: Additional parameters can be passed through the URL to filter or control the the target application's behavior. Using the runtime parameter listings from the application may be helpful.
• Map Fields to Target Application: Only used if calling your task from a maintainer. With this option, you are able to map any fields from the maintainer to the fields of your target application. If not calling this task from a maintainer, this option can be ignored.
• Output Format: Choose the format you would like to output your application to. Note: Retrievals only support output to HTML and text formats.

Recipients

• Send one Target Application for all recipients: Selecting this option will run the application one time and deliver the same application in the same email to all recipients (hardcoded or from a distribution list). For example, if there are five recipients, the application will run once and all five addresses will get the same email and application.
• Send one Target Application per recipients: Selecting this option will run and deliver the application separately for each recipient returned (hardcoded or from a distribution list). For example, if there are five recipients, the application will run once and send the email to the first recipient. Then the application will run again and be delivered to the second recipient. This will continue until all recipients have been sent an email.
• Send Target Application to address from web form: This option can only be used if invoking your task from a maintainer. Enter the field from the maintainer that will hold the email address to deliver the email to as well as the optional CC email address field name.
• Retrieve List of Addresses from Database Table?: This option allows you to use a Distribution List Retrieval to send your emails. Select the dictionary where the Distribution List Retrieval lives and the Retrieval application itself. Any additional parameters you wish to pass to filter retrieval results can be entered here as well.
• Filter Distribution List using Maintainer Form Input: If a Distribution List is selected and you are triggering this task from a maintainer, you are able to filter the distribution list dynamically by mapping fields from the maintainer to the Distribution List Retrieval. For example, if you have a customer order form maintainer triggering your task group, you can map CUSNO (customer number) from the maintainer to filter the Distribution List's records to only return emails for their customer number. This is a dynamic way to send emails from a maintainer.
• Filter Target Application using Distribution List: If using a distribution list, you can filter the target application records by mapping fields from the Distribution List Retrieval to fields in the target application. For example, you can map CUSNO (customer number) from the distribution list to the CUSNO field of the target application and when using the 'Send one Target Application per recipients' option, send each customer their own data.
• Additional Addresses: Enter any hardcoded email addresses here that you wish to always receive an email. Multiple addresses may be added separated by a comma.

Email Info

• Sender: This will be the 'from' address when the recipient receives their email. This needs to be a working email address. If left blank, the sender address will pull from the configuration file.
• Message Subject: Controls the subject of the email. If passing any parameters to the target application via the additional parameters box or mapping fields, you can use these parameters in the filename as well. For example, if mapping CUSNO from a maintainer to the CUSNO field of the target application, you can use 'Results for ${CUSNO}' as the subject line. You may also use built in variables to pull current timestamp or date when the task is ran. Use ${timestamp} or ${datestamp} for these respectively.
• Attachments: List the filenames (included file extension) of any static attachments that will always be attached to the email. These files need to be stored on the m-Power server in /mrcjava/job_streams/attachments. Multiple files can be listed separated by a comma.

Review

• Review: Overview of all options that make up your task. A great tool for troubleshooting tasks.

Run a Summary

Target Application

• Summary: Select the dictionary and summary that you wish to use in your task.
• Additional Parameters: Additional parameters can be passed through the URL to filter or control the the summaryies behavior. Using the runtime parameter listings from the application may be helpful.

Review

• Review: Overview of all options that make up your task. A great tool for troubleshooting tasks.

Save Application Output to Server

Target Application

• Target Application: Select the dictionary and application that you wish to use in your task. You can use a Retrieval or Report for this task type.
• Additional Parameters: Additional parameters can be passed through the URL to filter or control the the target application's behavior. Using the runtime parameter listings from the application may be helpful.
• Map Fields to Target Application: Only used if calling your task from a maintainer. With this option, you are able to map any fields from the maintainer to the fields of your target application. If not calling this task from a maintainer, this option can be ignored.
• Output Format: Choose the format you would like to output your application to. Note: Retrievals only support output to HTML and text formats.
• Filename: Only used if sending the report as an attachment. File extension is required when naming file (.pdf, .xlsx, .txt, etc). If passing any parameters to the report via the additional parameters box or mapping fields, you can use these parameters in the filename as well. For example, if mapping CUSNO from a maintainer to the R001 (first runtime record selection) of the report, you can use 'Report_${R001}.xlsx' as the filename. You may also use built in variables to pull current timestamp or date when the task is ran. Use ${timestamp} or ${datestamp} for these respectively.

Recipients

• Output one Target Application: Selecting this option will run the application one time and generate one application output to the server.
• Output one Target Application per distribution record: Selecting this option will run and and generate the application separately for each recipient returned from a distribution list. If this option is selected, you must use a distribution list. For example, if there are five records returned in the distribution list , the application will run once and send the output to the server. Then the application will run again and be delivered to the server as a separate file. This will continue until all records have had a file generated on the server.
• Retrieve List of Addresses from Database Table?: This option allows you to use a Distribution List Retrieval to control the output files that are generated. Select the dictionary where the Distribution List Retrieval lives and the Retrieval application itself. Any additional parameters you wish to pass to filter retrieval results can be entered here as well.
• Filter Distribution List using Maintainer Form Input: If a Distribution List is selected and you are triggering this task from a maintainer, you are able to filter the distribution list dynamically by mapping fields from the maintainer to the Distribution List Retrieval. For example, if you have a customer order form maintainer triggering your task group, you can map CUSNO (customer number) from the maintainer to filter the Distribution List's records to only return records for their customer number. This is a dynamic way to generate files based on record data.
• Filter Target Application using Distribution List: If using a distribution list, you can filter the target application records by mapping fields from the Distribution List Retrieval to fields in the target application. For example, you can map CUSNO (customer number) from the distribution list to the CUSNO field of the target application and when using the 'Output one Target Application per distribution record' option, create a separate output file for each customer returned in the distribution list.
• Queue: Select the directory queue to control where the files will be generated on the server. These queues are set up in the Message Queue Setup page from the Messaging Menu.

Review

• Review: Overview of all options that make up your task. A great tool for troubleshooting tasks.

Send an SMS Text Message

Target Application

• Target Application: Select the dictionary and application that you wish to use in your task. You can use a Retrieval or Report for this task type.
• Additional Parameters: Additional parameters can be passed through the URL to filter or control the the target application's behavior. Using the runtime parameter listings from the application may be helpful.
• Map Fields to Target Application: Only used if calling your task from a maintainer. With this option, you are able to map any fields from the maintainer to the fields of your target application. If not calling this task from a maintainer, this option can be ignored.

Recipients

• Send one Target Application for all recipients: Selecting this option will run the application one time and deliver the same application in the same SMS text to all recipients (hardcoded or from a distribution list). For example, if there are five recipients, the application will run once and all five phone numbers will get the same SMS text and application.
• Send one Target Application per recipients: Selecting this option will run and deliver the application separately for each recipient returned (hardcoded or from a distribution list). For example, if there are five recipients, the application will run once and send the SMS message to the first recipient. Then the application will run again and be delivered to the second recipient. This will continue until all recipients have been sent an SMS message.
• Send Target Application to address from web form: This option can only be used if invoking your task from a maintainer. Enter the field from the maintainer that will hold the phone number to deliver the message to.
• Retrieve List of Addresses from Database Table?: This option allows you to use a Distribution List Retrieval to send your text messages. Select the dictionary where the Distribution List Retrieval lives and the Retrieval application itself. Any additional parameters you wish to pass to filter retrieval results can be entered here as well.
• Filter Distribution List using Maintainer Form Input: If a Distribution List is selected and you are triggering this task from a maintainer, you are able to filter the distribution list dynamically by mapping fields from the maintainer to the Distribution List Retrieval. For example, if you have a customer order form maintainer triggering your task group, you can map CUSNO (customer number) from the maintainer to filter the Distribution List's records to only return phone numbers for their customer number. This is a dynamic way to send SMS messages from a maintainer.
• Filter Target Application using Distribution List: If using a distribution list, you can filter the target application records by mapping fields from the Distribution List Retrieval to fields in the target application. For example, you can map CUSNO (customer number) from the distribution list to the CUSNO field of the target application and when using the 'Send one Target Application per recipients' option, send each customer their own data.
• Additional Addresses: Enter any hardcoded phone numbers here that you wish to always receive an SMS message. Multiple phone numbers may be added separated by a comma.

Review

• Review: Overview of all options that make up your task. A great tool for troubleshooting tasks.

Call a Maintainer Application

Target Application

• Select Maintainer: Select the dictionary and maintainer that you wish to use in your task.
• Additional Parameters: Additional parameters can be passed through the URL to filter or control the the maintainer's behavior. Using the runtime parameter listings from the application may be helpful.
• Map Fields to Maintainer: Only used if calling your task from a maintainer. With this option, you are able to map any fields from the maintainer to the fields of your target maintainer. If not calling this task from a maintainer, this option can be ignored.

Recipients

• Retrieve List of Addresses from Database Table?: This option allows you to use a Distribution List Retrieval to bring back records to use in your target maintainer. Select the dictionary where the Distribution List Retrieval lives and the Retrieval application itself. Any additional parameters you wish to pass to filter retrieval records can be entered here as well.
• Filter Distribution List using Maintainer Form Input: If a Distribution List is selected and you are triggering this task from a maintainer, you are able to filter the distribution list dynamically by mapping fields from the maintainer to the Distribution List Retrieval.
• Filter Target Application using Distribution List: If using a distribution list, you can filter the target application records by mapping fields from the Distribution List Retrieval to fields in the target application.

Review

• Review: Overview of all options that make up your task. A great tool for troubleshooting tasks.

Merge Data to PDF and Save to Server

Target Application

• Target Application: Select the dictionary and Merge Data to PDF Retrieval that you wish to use in your task.
• Additional Parameters: Additional parameters can be passed through the URL to filter or control the the target retrieval's behavior. Using the runtime parameter listings from the application may be helpful.
• Map Fields to Target Application: Only used if calling your task from a maintainer. With this option, you are able to map any fields from the maintainer to the fields of your target retrieval. If not calling this task from a maintainer, this option can be ignored.
• Output Format: Choose the format you would like to output your application to.
• Filename: Required for this message type. File extension must also be .pdf. If passing any parameters to the report via the additional parameters box or mapping fields, you can use these parameters in the filename as well. For example, if mapping CUSNO from a maintainer to the CUSNO field of the retrieval, you can use 'Output_${CUSNO}.pdf' as the filename. You may also use built in variables to pull current timestamp or date when the task is ran. Use ${timestamp} or ${datestamp} for these respectively.

Recipients

• Send one Retrieval for all recipients: Selecting this option will run the retrieval one time and generate the retrieval output to the server.
• Send one Retrieval per recipients: Selecting this option will run and and generate the retrieval separately for each recipient returned from a distribution list. If this option is selected, you must use a distribution list. For example, if there are five records returned in the distribution list, the application will run once and send the output to the server. Then the application will run again and be delivered to the server as a separate file for the next record in the distribution list. This will continue until all records have had a file generated on the server.
• Retrieve List of Addresses from Database Table?: This option allows you to use a Distribution List Retrieval to control the output files that are generated. Select the dictionary where the Distribution List Retrieval lives and the Retrieval application itself. Any additional parameters you wish to pass to filter retrieval results can be entered here as well.
• Filter Distribution List using Maintainer Form Input: If a Distribution List is selected and you are triggering this task from a maintainer, you are able to filter the distribution list dynamically by mapping fields from the maintainer to the Distribution List Retrieval. For example, if you have a customer order form maintainer triggering your task group, you can map CUSNO (customer number) from the maintainer to filter the Distribution List's records to only return records for their customer number. This is a dynamic way to generate files based on distribution list record data.
• Filter Target Application using Distribution List: If using a distribution list, you can filter the target application records by mapping fields from the Distribution List Retrieval to fields in the target application. For example, you can map CUSNO (customer number) from the distribution list to the CUSNO field of the target application and when using the 'Send one Retrieval per recipient' option, create a separate output file for each customer returned in the distribution list.
• Queue: Select the directory queue to control where the files will be generated on the server. These queues are set up in the Message Queue Setup page from the Messaging Menu.

Review

• Review: Overview of all options that make up your task. A great tool for troubleshooting tasks.

Merge Data to PDF and Send via Email

Target Application

• Target Application: Select the dictionary and Merge Data to PDF Retrieval that you wish to use in your task.
• Additional Parameters: Additional parameters can be passed through the URL to filter or control the the target retrieval's behavior. Using the runtime parameter listings from the application may be helpful.
• Map Fields to Target Application: Only used if calling your task from a maintainer. With this option, you are able to map any fields from the maintainer to the fields of your target retrieval. If not calling this task from a maintainer, this option can be ignored.
• Output Format: Choose the format you would like to output your application to.
• Filename: Required for this message type. File extension must also be .pdf. If passing any parameters to the report via the additional parameters box or mapping fields, you can use these parameters in the filename as well. For example, if mapping CUSNO from a maintainer to the CUSNO field of the retrieval, you can use 'Output_${CUSNO}.pdf' as the filename. You may also use built in variables to pull current timestamp or date when the task is ran. Use ${timestamp} or ${datestamp} for these respectively.

Recipients

• Send one Retrieval for all recipients: Selecting this option will run the application one time and deliver the same application in the same email to all recipients (hardcoded or from a distribution list). For example, if there are five recipients, the retrieval will run once and all five addresses will get the same email and retrieval output.
• Send one Target Application per recipients: Selecting this option will run and deliver the application separately for each recipient returned (hardcoded or from a distribution list). For example, if there are five recipients, the application will run once and send the email to the first recipient. Then the application will run again and be delivered to the second recipient. This will continue until all recipients have been sent an email.
• Send Target Application to address from web form: This option can only be used if invoking your task from a maintainer. Enter the field from the maintainer that will hold the email address to deliver the email to as well as the optional CC email address field name.
• Retrieve List of Addresses from Database Table?: This option allows you to use a Distribution List Retrieval to send your emails. Select the dictionary where the Distribution List Retrieval lives and the Retrieval application itself. Any additional parameters you wish to pass to filter retrieval results can be entered here as well.
• Filter Distribution List using Maintainer Form Input: If a Distribution List is selected and you are triggering this task from a maintainer, you are able to filter the distribution list dynamically by mapping fields from the maintainer to the Distribution List Retrieval. For example, if you have a customer order form maintainer triggering your task group, you can map CUSNO (customer number) from the maintainer to filter the Distribution List's records to only return emails for their customer number. This is a dynamic way to send emails from a maintainer.
• Filter Target Application using Distribution List: If using a distribution list, you can filter the target application records by mapping fields from the Distribution List Retrieval to fields in the target application. For example, you can map CUSNO (customer number) from the distribution list to the CUSNO field of the target application and when using the 'Send one Retrieval per recipients' option, send each customer their own data.
• Additional Addresses: Enter any hardcoded email addresses here that you wish to always receive an email. Multiple addresses may be added separated by a comma.

Email Info

• Sender: This will be the 'from' address when the recipient receives their email. This needs to be a working email address. If left blank, the sender address will pull from the configuration file.
• Message Subject: Controls the subject of the email. If passing any parameters to the target application via the additional parameters box or mapping fields, you can use these parameters in the filename as well. For example, if mapping CUSNO from a maintainer to the CUSNO field of the target application, you can use 'Results for ${CUSNO}' as the subject line. You may also use built in variables to pull current timestamp or date when the task is ran. Use ${timestamp} or ${datestamp} for these respectively.
• Message: Hardcode any text to appear in the body of the email. For example, "Thank you for the order."
• Attachments: List the filenames (included file extension) of any static attachments that will always be attached to the email. These files need to be stored on the m-Power server in /mrcjava/job_streams/attachments. Multiple files can be listed separated by a comma.

Review

• Review: Overview of all options that make up your task. A great tool for troubleshooting tasks.

Built-in Date Parameters

If needing to pass a dynamic date or date range to a target application, the Additional Parameters section can be used. Type the field in which the date value will be passed to and use one of the date parameters listed below.

Note: All values are returned in ISO format (YYYY-MM-DD). If your application field is expecting a different format or is a numeric date field, append the parameter 'dateformat=yyyy-MM-dd' to the Additional Parameters box. For example; R001=${today}&dateformat=yyyy-MM-dd. This will tell the target application to translate the ISO date into the expected format.

Note: Variables that return a range are separated by a space.

Note: Fiscal dates are determined from the 'fiscal_month' setting in the mrcjava/WEB-INF/classes/mrc_runtime.properties file found on the m-Power server (i.e. fiscal_month=5).

Assuming the current date is 2018-01-10, the date parameters would return the following values:

${today} — Current date (2018-01-10)
${tomorrow} — Tomorrow's date (2018-01-10)
${yesterday} — Yesterday's date (2018-01-09)
${thisweek} — Sunday to Saturday of the current week (2018-01-07 2018-01-13)
${thisweektodate} — Sunday of the current week to the current date (2018-01-07 2018-01-10)
${lastweektodate} — Sunday of the previous week to the current week day of the previous week (2017-12-31 2018-01-03)
${lastweek} — Sunday and Saturday of the previous week (2017-12-31 2018-01-06)
${nextweek} — Sunday to Saturday of the following week (2018-01-14 2018-01-20)
${thismonth} — First day of the current month to the last day of the current month (2018-01-01 2018-01-31)
${thismonthtodate} — First day of the current month to the current day of the current month (2018-01-01 2018-01-10)
${nextmonth} — First day of the following month to the last day of the following month (2018-02-01 2018-02-28)
${lastmonth} — First day of the previous month to the last day of the previous month (2017-12-01 2017-12-31)
${lastmonthtodate} — First day of the previous month to the current day of the previous month (2017-12-01 2017-12-10)
${thisquarter} — First day of the current quarter to the last day of the current quarter (2018-01-01 2018-03-31)
${lastquarter} — First day of the previous quarter to the last day of the previous quarter (2017-10-01 2017-12-31)
${thisyear} — First day of the current year to the last day of the cuBrrent year (2018-01-01 2018-12-31)
${nextyear} — First day of the following year to the last day of the following year (2019-01-01 2019-12-31)
${lastyear} — First day of the previous year to the last day of the previous year (2017-01-01 2017-12-31)
${thisyeartodate} — First day of the current year to the current date (2018-01-01 2018-01-10)
${lastyeartodate} — First day of the previous year to the current day of the previous year (2017-01-01 2017-01-10)
${thisquarterfiscal} — First day of the current fiscal quarter to the last day of the current fiscal quarter (2017-11-01 2018-01-31)
${lastquarterfiscal} — First day of the previous fiscal quarter to the last day of the previous fiscal quarter (2017-08-01 2017-10-31)
${thisyearfiscal} — First day of the current fiscal year to the last day of the current fiscal year (2017-05-01 2018-04-30)
${lastyearfiscal} — First day of the previous fiscal year to the last day of the previous fiscal year (2016-05-01 2017-04-30)
${thisyearfiscaltodate} — First day of the current fiscal year to the current date (2017-05-01 2018-01-10)
${lastyearfiscaltodate} — First day of the previous fiscal year to the current day of the previous fiscal year (2016-05-01 2017-01-10)

Executing Task Groups

Executing Task Groups

Messaging and scheduled tasks can be used to automate many m-Power processes and can be executed in three different ways. The first is through the task and message groups screen. To get there, click Admin Menu, Utilities, and then Messaging & Scheduled Tasks.

Once the task group has been created it can be executed. Click on the green arrow button under the Test column to run these tasks ad-hoc. Once the system is finished running the task, a message will display stating that the task group has been successfully processed.

The second method to execute a task group is through the scheduler. To get there, click on Messaging Menu and then Scheduled Tasks. A new scheduled task must be created. To do so, click on the Create New Scheduled Task button. Now, select a task group and how often the task group needs to be run. Tasks can be run every minute, hour, day, week, month, or year. There is also a custom option that can be used to customize the frequency that task groups are run. The next step is to reload Tomcat. To do so, click on the link in the message in the blue box on the screen.

The final method to execute a task group is through the after actions tab in a maintainer. Select a maintainer and click on Edit Properties. Then, click on the After Actions tab in the application properties activity. Navigate down to the add_message, update_message, delete_message, and all_mesage fields. Here, enter which task group to call after a user either adds, updates, or deletes a record in this maintainer. Please note that the task group field is case-sensitive – the task group will need to be entered exactly as it appears on the Messaging and Scheduled Tasks screen.

 

Scheduled Tasks

Controls any task groups that wish to be scheduled. Choose a task group or business rule process. Select a frequency to run the task group. The custom frequency scheduler uses Cron expressions to trigger tasks. Please see the CronTrigger Tutorial for help with using the custom frequency scheduler. Tomcat needs to be reloaded in order for any changes from the scheduler to take effect.

Message Queue Setup

Controls the directory paths used for the 'Save Application Output to Server' and 'Merge Data to PDF and Save to Server' message types. Assign a name for the queue and an absolute directory path as the Queue Path. Note: The queue path only supports output to a local drive. You cannot use a shared network folder to write to.

Configuring the Messaging and Scheduled Tasks Utility

Properties

• mpower_server: Required for any part of the messaging and scheduled task utility to function. Use 'https://localhost:PORT' where PORT is the port number your m-Power is installed on. If your m-Power server references itself by another name, use that instead of localhost.
• email_sender: Controls the 'From' address for emails that are sent from the utility. Can be overridden at the task level.
• email_server: The IP address of your email server.
• email_user: Email account user.
• email_password: Email account password. May not be required by email server.
• email_other: Any other additional logic needed from your email server. Often used when using an SSL authenticated server. May not be required for your email server. For example, gmail uses the following additional logic, 'mail.smtp.starttls.enable:true'.
• enable_scheduler: Available values are 'true' or 'false'. Needs to be 'true' if any tasks are scheduled. Likely want to disable the scheduler in development, but enable in production.
• sms_user: SMS relay account user.
• sms_from: SMS relay 'from' phone number.
• sms_password: SMS relay account password.

Message Logger

The Message Logger is accessible from the Messaging Menu and is a helpful tool when troubleshooting your tasks. All tasks that are executed either from being scheduled, manually triggered with the test task button, or triggered from a maintainer are logged to the scheduler.log file. This is made available to you view via the interface.

Promoting Task Groups to Production

To promote task groups to production you will need to move all the applications involved: the target application, the Distribution List Retrieval (if used), and the maintainer if one was used. These applications will be promoted in the regular way. You also need to promote specific messaging files in addition to the application files. These are the files, and their corresponding locations:

• mrc_distribution_jobs_mysql1.txt         \m-power\mrcjava\job_streams
• mrc_distributions.txt                              \m-power\mrcjava\WEB-INF\classes\DICTIONARY
• message-queue.properties                   \m-power\mrcjava\job_streams
• messaging.properties                             \m-power\mrcjava\job_streams

The mrc_distribution_jobs_mysql1.txt file stores all of your scheduled jobs. It also references your database connection in the filename. If your m-Power is connecting to an AS400, it would be: _AS400_remote1.
The message-queue.properties file stores the queue directory paths set in the Message Queue Setup page.
The mrc_distributions.txt file stores all of the tasks and task groups per dictionary.
Note: The above three files will need to be promoted every time a new message task has been created or modified if wanting to use them in production.

The messaging.properties file is the configuration file and is located in \m-power\mrcjava\job_streams. This file needs to be promoted only once, unless the configuration properties of the email server changes, then it will need to be promoted again. After the messaging.properties file is promoted, the mpower_server field will need to be modified to point to the correct port for the production instance. After this is done, Tomcat will need to be restarted.

Stopping Scheduled Tasks from Running in Development

After promoting your messaging files to production, your tasks will immediately run in both production and development. Should you wish to stop the task from running in development, you can do so by returning to the Task & Message Configuration page and disabling the scheduler like so:

enable_scheduler=false

Tomcat will need to be restarted for this to take effect. With this done, you will no longer be able to run a scheduled task through development.  However, you will be able to create and set the scheduled task, so that once promoted, it runs as scheduled.  Additionally, you can still test the task in development with the green test task arrow button. Note: If you accidentally promote the messaging.properties file to production again, scheduled tasks will no longer run in production because of the disabled scheduler. Simply edit the file in production again to have your scheduled tasks run.

Additional information Links

Messaging and Scheduled Tasks Real Life Example
How to Send Emails to a Table Driven List of Recipients (Distribution List)