Application Messages and Detailed Messages
This document explains what application messages are and how they are used to facilitate and automate your daily work in M3 Business Engine (BE).
It also describes how detailed messages that are connected to an application message can be used to gain in-depth knowledge about the errors that triggered the application message. Note that although application messages are used in all parts of M3 BE, detailed messages are only used in some M3 BE applications.
Before you start
For information about how the application message functionality is set up, see Set Up the M3 Application Message System.
Purpose
Application messages
Application messages are used to notify a responsible person that an incident has happened that requires attention. The application message can be informational or it can indicate an error or a disruption from the normal work flow. Whatever the nature of the application message, the responsible person must often perform a task in response to the message.
An application message can be used as in these examples:
- An authorizer is notified that an automatic matching of invoices was not approved, since the price variances between the invoices were outside the tolerance range.
- A person responsible for a work order is notified that work on the order has started.
- A person responsible for a purchase order is notified that the delivery of goods is delayed.
Application messages are used throughout M3 BE.
Application messages can also be set to trigger alerts, tasks, notifications, or workflows to be created in ION.
Detailed messages
The incidents that create application messages often result in errors or information that requires action. For example, when a planned manufacturing order will be released, errors can prevent the order from being released.
In such cases the application message can be vague, for example "planned order not released". However, detailed messages can explain in detail each error or incident that occurred when the release of the order failed. These detailed messages are easy to overview, since they are grouped together and are connected to the application message.
When and how
Application messages
The application message is generated automatically and is displayed for the responsible person in 'Application Message. Open' (CRS420) every time the incident happens.
The person who is responsible for taking action depends on the type of message. Usually it is the person set as the responsible person, the planner, the approver, or the authorizer for the record that the message refers to, the activity or the workflow in M3 BE.
The application message can also be sent as an email. The responsible person is then notified automatically when the incident occurs and does not have to open (CRS420) to check if any new messages were generated. The message is sent by email if the person's email address is specified in 'Email Address. Open' (CRS111), and the email setting is activated for the user in 'Application Message E-mail Param. Open' (CRS427).
Detailed messages
In some cases the detailed messages are generated together with the application message. The detailed messages are displayed in 'Detailed Mail Message. Open' (CMS421). This program can be accessed in these ways:
- From the menu.
- From the application message by selecting an option in (CRS420).
- From different programs related to the creation of the detailed messages. For example, detailed messages can be generated when you work with the implementation of action logs in M3 Manufacturing if the implementation fails. The detailed messages can then be accessed from the action log in 'Action Log. Open' (CMS050) and from a single action in 'Actions. Open' (CMS051).
When (CMS421) is opened, the detailed message displayed at the top of the list is the first one connected to the application message (except when the program is accessed from the menu). The reference to the application message is the field 'Data ID'. All detailed messages connected to the same application message have the same data ID. Note that while an application message is only displayed for the person who is responsible for it, all detailed messages are displayed for all users.
To avoid spam, the detailed messages are not sent as emails.
Also note that when a job is rerun, all detailed messages that were generated when the job was performed the first time are automatically deleted. A practical example of this is when the implementation of an action log in M3 Manufacturing failed. When the action log is implemented again, all detailed messages that were generated earlier are deleted regardless of whether they are set as corrected.
Application messages connected to workflows in ION
Application messages can be set to trigger the publication of a ProcessWorkflow BOD that can start a workflow in ION. The BOD contains data related to the application message, such as application message ID and message text, and data related to the record in M3 BE that triggered the message, such as table and key field values.
If the workflow was started successfully, ION will respond to M3 BE with an Acknowledge BOD including the workflow ID and status of the started workflow. This information, together with the message ID and key values for the related M3 record, are updated in the M3 BE table (CWKFLK workflow information) through API CRS420MI.
The workflow ID for an application message is displayed in field 'External ref' (EXRE) and the workflow status in field 'External status' (EXRS) on (CRS420/E) for the applicable application message. The fields become visible if they contain a value.
The workflow ID for a related record in M3 BE can also be displayed in programs with configurable list view, listed in program 'List and Printer programs. Configure' (CMS005) by adding the virtual field '&EXRE' to the view. Run related option 'Update standard' in (CMS005) to add this field to the program field group if this is not already there. Only one workflow ID can be displayed in the list for one record even if several workflows possibly could be triggered for the same object. In this case, the workflow ID for the most recent workflow will be displayed.
To configure an application message to be sent as a workflow BOD to ION, open (CRS424) and select the parameters 'Activity code', 'BOD enabled', and 'BOD msg type' 4-'Workflow' for the applicable message type. A workflow name must also be specified with an exact match (both upper and lower case) to the name of an active workflow existing in ION.
For the application message type 012 – 'Event-based messages', only the 'Activity code' and the 'BOD enabled' parameters must be selected. All other settings are made in program 'Event Based Alerts. Open' (CMS047).
API transactions to manage workflow information
This table shows the transactions in CRS420MI that are applicable for managing records in the workflow table:
| Transaction | Description |
|---|---|
| AddExtRefInfo | Add workflow information to an application message. |
| GetExtRefInfo | Retrieve workflow information for an application message. |
| DltByExtRef | Delete by external reference (workflow) for an application message. |
| DltExtRefInfo | Delete workflow information for a specific application message. |
| DltExtRefMulti | Mass delete workflow information for application messages. |
| LstExtRefInfo | List workflow information for application messages. |
| UpdByExtRef | Update by external reference (workflow) for an application message. |
| UpdExtRefInfo | Update workflow status for an application message. |
In all the API transactions, the 'Reason code' (RECD) will be defaulted to 1-'Workflow' if left blank. In the 'AddExtRefInfo' transaction, the 'Mail' (MLID) or 'Table' (FILE) and 'Key string' (KEYS) must be specified. If only MLID is specified, the FILE and KEYS will automatically be retrieved from the record in the CMAILP table.
The transactions DltByExtRef and UpdByExtRef deletes or updates workflow information by external reference (EXRE) and reason code (RECD).
We recommend that you clear the CWKFLK table from completed workflows on a regular basis, since the number of records can grow over time. The API transaction 'DltExtRefMulti' has been created for this purpose. In this transaction, the 'Change date' (LMDT) is mandatory and records prior or equal to this date will be deleted. If 'Table' (FILE) is not specified, the records for all tables will be deleted. If 'Status' (EXRS) is left blank, all records with status 'Completed' and 'Cancelled' will be deleted. The number of deleted transactions is displayed as output for the transaction.
Temporary authorization
Application messages
If the responsible person is away from work, for example due to sickness or vacation, another person can obtain access to process or view the application messages that are generated. This is useful since many application messages demand immediate attention.
When you grant another person authorization, you set up a valid date range and a level of authorization. The available levels are as follows:
- Process the responsible person's application messages. For this level specify what the person can and cannot do, for example change the status of the application message or grant yet another user temporary authorization.
- Receive and review the responsible person's application messages.
- Receive and review a copy of the responsible person's application message.
You can limit these levels for the user to apply only for a specific application message type.
You set up the temporary authorization in 'Application Message. Connect Authority' (CRS422). This program is accessed by selecting a function key in (CRS420).
Detailed messages
It is not possible to grant temporary authorization to detailed messages, since these messages are not connected to a specific person.
How to process the messages
The messages usually indicate an error that must be corrected or a task that should be performed. You can often access the program where you take action by selecting the option Open (11) for the message in (CRS420) or (CMS421).
By directly accessing the program, the work flow is considerably automated; you do not have to spend time finding out which program to start.
Application messages
After you have read an application message you can, for example, do these activities:
- Plan when to perform the task. If you do not want to take any action immediately, you can set an end date when the message should be dealt with in the 'Action date' field on (CRS420/E). This is used to keep track of the application message. Later during searching, you can sort application messages by action date.
- Perform the task. If there is no detailed message functionality connected to the application message, you can often access the program where you perform the task by selecting the option Open (11) for the message in (CRS420). After the task is performed, you can set the application message as completed by entering a date in 'Completed date' on (CRS420/E).
- If there are detailed messages connected to the application message, you can open these to further investigate what triggered the application message and then correct the detailed messages one by one. When all of them are corrected, you set the application message as completed as described above. The section Detailed Messages describes how to process detailed messages.
- File the application message if no further action needs to be taken. This can be the case when the application message has status 50–'Completed', or if it is only a copy and therefore has status 80–'Copy'. You file a message by selecting the option File-'24' in (CRS420).
Status for Application Messages
You can use status codes to manage application messages. You can also search for and display only the application messages that you are interested in.
These status codes are available:
- 10–'New'. The applications message is generated but not opened.
- 20–'Opened'. The application message is opened in (CRS420).
- 30–'Forwarded'. The application message is forwarded to the person who has temporary authorization.
- 40–'Replied'.
- 50–'Completed' action. The application message has a completed action. A task is completed and a completion date is specified.
- 80–'Saved copy' of message is sent. The application message has been sent to a person who has temporary authorization. The message that has status 80 is the original message.
- 90–'Archived'. The application message is archived.
Detailed messages
After you have read a detailed message, you can perform the task needed to correct the message. You access the program where you perform the task by selecting option-'11' for the message in (CMS421).
After you are finished, you set the status of the detailed message to 90 (Blocked/expired) to indicate that it is completed. If all detailed messages are corrected, you can set the application message to completed, as described above.
Status for Detailed Message
You can use status codes to manage detailed messages.
- 20–'Definite'. The detailed message is not corrected.
- 90–'Blocked/Expired'. The detailed message is corrected and completed.