SAP Q&A - MII Alert Framework Guide...MII Alert Framework Guide Page 9 of 28 Mail body : Consists of...

MII Alert Framework Guide

SAP® MII Alert Framework Guide

© 2012 SAP Labs India Pvt Ltd

MII Alert Framework Guide Page 2 of 28

1 Introduction .. ……………………………………………………………….. 3

2 Alert Definition………………………………………………………………3

2.1 Defining an alert……………………………………………………………...3

2.2 Role Mapping of Alerts……………………………………………………....6

2.3 Raising an alert……………………………………………………………….7

2.3.1 Email notification on raising alerts…..……………………………………...7

2.3.2 Linkable parameters for raising alerts……………………………………..9

2.4 Deleting an Alert………………………………………………………….....10

2.4.1 Linkable parameters for deleting alerts…………………………………...11

2.5 Get Alerts…………………………………………………………………….12

2.5.1 Linkable parameters for get alerts…………………………………………12

2.6 Get Alert Details…………………………………………………………..…13

2.6.1 Linkable parameters for get alert details…………………………….……14

2.7 Forward Alerts…………………………………………………………...…..14

2.7.1 Linkable parameters for forward alerts……………………………..……..16

2.8 Set Alert Status……………………………………………………………....16

2.8.1 Linkable parameters for set alert status…………………………………...17

3 Alert WatchList……………………………………………………………...17

3.1 Set status of Alerts……………………………………………………...…...19

3.2 Delete Alerts……………………………………………………………….…20

3.3 Alert Logs………………………………………………………………….….20

3.4 Adding comments for Alerts………………………………………………...21

3.5 Forward Alerts………………………………………………………………..22

4 Alert Clean Up Rules…………………………………………………….....23

5 Alert Services………………………………………………………………..24

6 Appendix……………………………………………………………………..26




1 Introduction In manufacturing industries, there is a need to report events which occur in the shop floor or work area. The shop

floor would consist of a huge distribution of equipments in various lines. The maintenance of these equipments can be made easier with an Alert Framework. If one or more of these equipments breakdown or experience a technical glitch, the manager or supervisor of the line should be notified of the same so that the production is not hindered. This is where the Alert Framework plays a major role. On breakdown of a machine, an Alert will be triggered and the relevant person/people will be notified of the same via mail, sms etc. so that action can be taken on priority.

For example : If the temperature (KPI - key performance indicator) of a boiler exceeds or falls behind a specific threshold (50-100 deg Celsius), an alert can be configured to be raised and the supervisor will be notified that some action has to be taken to maintain the temperature of the boiler.

This document will take you through the Alert Framework which is an out-of-the-box feature in MII 14.0. In this release of MII, the user will be provided with the ability to define, raise and monitor an ‘Alert’ using the MII

Workbench. An Alert is a mechanism to notify the user about problems/errors or exceptions that occur in the shop floor. Alerts are Role based i.e. alerts will be visible to users based on their roles.

The Alert Framework is divided into three parts: the Alert Definition, Alert WatchList and the Alert CleanUp Rules, the details of which are explained further in the document.

2 Alert Definition

Alerts have their own file type. Files of this type would be located under the Object tab ->-> MIIOBJ directory of the MII file system. Users of the workbench would see these files under the ‘Objects’ tab in the file browser. All the alert action blocks can be found under the KPIs and Alerts section in the Actions tab of the alert

definition. User will be able to define Alerts as per the required specifications, on the MII Workbench using following configuration tabs:

General

Role Mapping

Security

2.1 Defining an Alert 1. Navigate to the MII workbench -> go to the object tab - > right click on MIIOBJ folder and select the ‘Alert’

option.




Defining an alert

2. Configure the general properties of the alert.

General tab to configure alerts




1. Short Text : This is a short description of the alert. This is a mandatory field. The definition cannot be

saved if this field is left blank. 2. Long Text : This is a detailed description of the alert.

A unique feature is available while defining short text and long text. These fields accept placeholder values (question mark, “?”) .These placeholders will be replaced dynamically by a list of strings at the time of raising the alert.

3. Expiration : This property specifies the expiry time of an alert in hours. The field takes an integer as

input. 4. Severity : This property specifies the severity of the alert (high, medium or low). 5. FollowUp Actions : These are name value pairs. The value could be any action that the user would be

allowed to perform on that alert. These values are specified as urls. Example : http://www.MachineAlertAction.com Follow up actions are an important attribute of an alert because alerts indicate some faulty behavior (breakdown of an equipment etc) and the supervisor/manager will be notified with these follow up actions, via mails/sms. He/she can click on the urls which would redirect to a possible solution to the problem.

6. Container Properties : These are name value pairs. They specify some metadata of the source of the

alert. Example : if an alert is raised from a machine, the metadata would be the location of that machine, the

line under which the machine is located, the equipment number etc. 7. Delivery Transaction: This field is used to define a transaction that is run when the alert is raised. This

transaction is run asynchronously.

If the user wants some action to be performed such as writing to a file etc, at the time of raising the alert, then he/she would have to create a transaction to perform the action and configure it as part of “Delivery Transaction” in the alert definition. On clicking the configure button in the delivery transaction tab of the general properties for an alert, he will be able to configure this delivery transaction. The following screen will pop up on clicking the Configure button. The user can then browse for the required transaction using the Browse button.

Configure Delivery Transaction

http://www.machinealertaction.com/




Once the configuration is complete, save the alert object created. The created alert object will be consumed in a Raise alert action block.

2.2 Role Mapping of Alerts

Role mapping for alerts is necessary because not all users/roles will want to view all the alerts in the system. A certain set of alerts will have to be assigned only to specific roles and the users without those roles will not want those alerts to be seen when they log into the system. Therefore it is necessary that alerts are mapped to roles at the time of defining alerts.

Example : In a business line, team 1 is responsible for a machine breakdown and team 2 is responsible for defects related to performance of the machines. When there is a machine breakdown, only team 1 would want to be notified of the breakdown whereas team 2 would not want any notifications for the same. This grouping would be possible only if alerts are mapped to roles.

Alerts are role based i.e. the user will be able to view the alerts only if he/she has the role that alert is mapped to. Roles can be mapped to the alerts in the Role Mapping screen. There are two exceptions to this rule :

If the user has the role of a super administrator (XMII_SUPER_ADMIN), he/she will be able to view all the alerts raised irrespective of the roles mapped to the alert.

Irrespective of the roles of the user he/she will be able to view all the alerts which have no roles mapped to them.




Role Mapping Screen

2.3 Raising an Alert

Raising an alert can be done by the Raise alert action block. An e-mail notification is sent to the users corresponding to the roles assigned in the Alert Definition. If no roles are defined there is no e-mail notification sent but the alert in the watch list screen (explained later in the document) will be visible to all the users.

2.3.1 Email Notification on raising alerts

E-Mail notifications will be sent to users on raising alerts only if the following configurations are in place: 1. Create a connection in the connections screen of MII with the following values

Name : MII_MAIL_CONFIG Server : mail.sap-ag.de Port : 25 Protocol : smtp

2. Create a credential in credential stores of MII with name : MII_MAIL_ADMIN Username and password same as windows user and password.

The mail format is as follows :

Subject : The text “Alert Notification” separated by a colon followed by the short text of the alert.




Mail body : Consists of the long text followed by the container properties and follow up actions.

Raising an alert can be done by the following steps

Create a transaction and add the Raise alert action block in the sequence.

Raise alert action block

On clicking the configure option of the raise alert action block, the user can browse the alert definition created previously to be raised. The following screen would then appear

Raise alert configuration




The configuration parameters are as follows:

Definition: This field allows the user to select a defined alert by clicking on ‘Browse’ button and selecting the

desired alert.

Raise Always: This check box is used if an alert has to be raised even if the same alert was raised

previously. Irrespective of whether the alert is in “New” or “In Process” status, the alert will be raised and will exist in the New status until further status change.

This feature will enable a business user to ensure receiving alerts on priority i.e. if he/she does not want certain alerts to be raised over and over again, he/she can restrict it using this flag. If the cause for the alert is of high priority and has to be processed immediately the user can choose to check the checkbox so that he/she will keep receiving alert notifications till the problem is fixed.

Severity: This field is used to define the severity of the alert at runtime.

Severity can also be configured at the time of raising the alert. When the user sets the severity here, the previously defined severity (in the alert definition) will be overridden. The same is applicable for followup actions and container properties as well.

Follow up Actions: This is a table containing name-URL pairs. This is used to define the actions to be

taken when an alert is raised. Here the actions defined as part of the definition cannot be deleted but can be edited, however new actions can be added.

Container Properties: This table is used to define context information relevant to this alert. Here the

properties defined as part of the definition cannot be deleted but can be edited, however new properties can be added.

2.3.2 Linkable parameters for raising alerts

Output on raising an alert (alert xml displayed)




Parameter Description

I/O Type

ShortText A list of values to be replaced against the placeholders

defined in the definition. Input and

Output List

LongText A list of values to be replaced against the placeholders

defined in the definition. Input and

Output List

FollowupActions A map of additional follow up actions other than the

ones defined in the definition. Input and

Output Map

ContainerProperties A map of additional container properties other than the

ones defined in the definition. Input and

Output Map

AlertPath The alert object to which the action refers to. The full

path has to be provided. This field cannot be null. Input and

Output String

RaiseAlways To indicate whether the alert has to be raised even if

there the same alert was raised on a previous occasion and still exists in the watch list

Input and Output

Boolean

Severity The severity of the alert. (Restricted to Low, Medium,

High) Input and

Output

String

Linkable parameters for raise alert action block

2.4 Deleting an Alert

Alerts can be deleted using the delete alert action block in the workbench. On clicking the configure option of the delete alert action block, the screen below appears where the details of the alerts to be deleted can be configured.




Delete alert action block configuration

The parameters to be configured are:

Definition: This field allows the user to select a defined alert by clicking on ‘Browse’ button and selecting the

desired alert.

Start Date: Date after which the alerts raised will be deleted.

End Date: Date before which the alerts raised will be deleted.

Status: The alert/alerts with the selected status/statuses will be deleted.

Severity: The alert/alerts with the selected severity/severities will be deleted.

Also note that for a given criteria, example - the status selected is Open and the severity selected is Low, then all the alerts (from the alert path chosen) with status as “Open” and severity “Low” for the selected start and end date will be deleted from the system.

2.4.1 Linkable parameters for deleting alerts

If no alerts are found for the given delete criteria, the following message will be displayed

Parameter Description I/O Type

AlertPath The alert object to which the action refers to. The full

path has to be provided. This field cannot be null. Input and

Output String

Start Date Date after which the alerts raised will be deleted. Input and

Output Timestamp

End Date Date before which the alerts raised will be deleted. Input and

Output Timestamp




Status The alert/alerts with the selected status/statuses will

be deleted. Input and

Output List

Severity The alert/alerts with the selected severity/severities

will be deleted. Input and

Output List

LastErrorMessage Determines whether the action passed or failed. Output String

Success Determines whether the action passed or failed. Output Boolean

Linkable parameters for delete alert action block

2.5 Get Alerts

Alerts can be fetched using the Get Alerts action block in the workbench.

On clicking the configure option of the get alerts action block, the follow screen appears where the details of the alerts to be obtained can be configured. This action block is used to get the alert ids of all the alerts which are part of the selected Alert and for the status that can be selected by the user. If no status is selected, then the alert ids of all the alerts raised for the specified alert definition file will be returned as the output of the action block.

Get Alerts configuration

The configuration parameters are as follows

Alert Name: Browse the folders for the alert full path.

Status: Status of the alerts for which the ids are expected. One or more status can be selected.

2.5.1 Linkable parameters for get alerts




Input parameters

Output on executing the transaction (Alert ids displayed)


LastErrorMessage Determines whether the action passed or

failed. Output String

Success Determines whether the action passed or

failed. Output Boolean

AlertIds List of all the alerts ids raised for the user

defined alert file Output List

AlertPath

The alert object to which the action refers to. The full path has to be provided. This field

cannot be null. Input String

Status List of status in which an alert can exist Input List

2.6 Get Alert Details

Alert details can be fetched using the Get Alert Details action block in the workbench. This action block is used to get various details of an alert in the form of an XML for the given alert id. The input is alert id that has to be specified by the user.

On clicking the configure option of the get alert details action block, the follow screen appears where the details of the alerts to be obtained can be configured. The alert id is the only linkable parameter for this action block

Get alert details configuration




2.6.1 Linkable parameters for get alert details action block


AlertId Numeric value, provided by the user as the id

of the alert for which details are required Input Integer

Output on executing the transaction (Alert xml displayed)

2.7 Forward Alerts

Alerts can be forwarded to users with roles using the Forward Alert action block in the workbench.

This action block is used to forward a given alert to one or more roles existing in the system. The input is alert ids of one or more alerts that have to be forwarded and the list of user roles to which the alerts have to be forwarded. On clicking the configure option of the forward alert action block, the follow screen appears where the details of the alerts to be forwarded can be configured.




Forward alert configuration

The parameters are:

Alert Id: List of alert ids that have to be forwarded

Roles: List of user roles to which the specified alerts have to be forwarded




2.7.1 Linkable parameters for forward alert action block


AlertId Numeric value, provided by the user as the id of the alerts which have to be forwarded

Input List

Roles List of user roles to which the given alerts have to be forwarded

Input List

2.8 Set Alert Status

The status of an alert can be changed using the “Set Alert Status” action block. The input is alert id that have to be specified by the user. Any alert that is already in the ‘Acknowledged’ state cannot be reverted to ‘New’ or ‘In Process’ state.

On clicking the configure option of the set alert status action block, the follow screen appears where the details of the alerts to be deleted can be configured.

Set alert status action block configuration

Alert Id: Numeric ids of the alerts for which the status needs to be set.

Alert Status: User can select one of the alert status from ‘New’, ‘In Process’ or ‘Acknowledged’.

The status changes can be summarized as follows :

Current Status Target Status Feasible (Y/N)

New In Process Y

New Acknowledged Y

In Process New Y

In Process Acknowledged Y

Acknowledged New N

Acknowledged In Process N




2.8.1 Linkable parameters for set alert status action block


Status The status to which the alert needs to be set.

This is a String value. Input String

AlertId

Numeric value, provided by the user as the id of the alert for which status needs to be

changed Input List

On successful change of status, the following message will be displayed

3 Alert WatchList The alerts that are raised from workbench as mentioned in section 2.2 are visible in the Alert Watchlist screen of the MII Menu. To view these alerts, navigate to the MII Menu -> Open the group “Alerts and KPI” -> Alert WatchList.

This screen is a role based screen i.e. the user who has logged in to MII would have a specific set of roles and only the alerts which have these roles mapped to them (as explained in section 2.1.1) will be visible to the user.

As we know now that all alerts have a status associated with them i.e. New, InProcess, Acknowledged and Expired. The state transition is as shown in the diagram below :

New InProcess Acknowledged

Expired

End of lifetime

End of lifetimeEnd of lifetime

State Transition diagram for Alerts




The states are :

New : This is the default state of the alert. When an alert is raised, it is in the new status.

In Process : When a newly created alert is picked to work upon, the status is changed to in-process.

Acknowledged : After the user has followed up on actions for an alert (fixed the problem), he can change

the status of the alert to acknowledged.

Expired : Every alert will exist in the system for a specified number of hours. A system job runs at a

scheduled interval to check if the lifetime of an alert is over, if yes, the alert is marked as expired. Alerts have a specified severity i.e. the importance with which the alerts need to be processed. The severity could be

Low : The alert is of minimum importance.

Medium : The alert is not of high priority and neither is it of low priority.

High : The alert is of high priority/importance and need to be processed immediately.

The Alert WatchList screen is as below

Alert WatchList screen




This screen is used to monitor alerts that are raised from the MII workbench. The main table displays the alerts the status and severity as shown. The Last Action Time depicts the time when some operation has been performed on the alert. Alerts can be filtered as per the specified criteria for filtering i.e.

Alerts can be filtered based on the status, severity, name/fullpath, start time and end time. This is done to make the search for specific alerts, simpler. The user can select Status or Severity from the dropdown in the first row of the table and on clicking enter, the alerts with only the selected status/ severity or both (if both are selected) will be displayed. The user can also use wildcard characters such as star (*) to perform filter on alert name. example – to look for an alert with the name “MachineAlert”, the user can simply enter “Mac*” which would return all alerts with the name beginning with “Mac”.

Filter on timestamp can be performed by giving just the date in the mm/dd/yyyy* format. Example - 10/19/2012*. All alerts with the given date raised at any time on that date will be filtered and displayed.

The screen is divided into different tabs :

1. General tab : This tab is used to display the general properties of the selected alert. These include the

name (fullpath) of the alert. The short and long text defined as part of the alert definition. Expiration time of the alert can also be seen here. The time the alert was raised and the time the last action was performed on it are also part of the general information of the alert. The status is the last field here along with the corresponding icons beside the text.

2. Follow-up Action tab : This tab is used to display the follow up actions as a link. Follow up actions are

name-value pairs. The link name is the “name” given to the follow up action and on clicking the link, the user will be directed to a web page the path of which is the url defined as the “value” of the follow up action.

3. Container Information tab: This tab is used to display the container information as name value pairs in a

table. These name-value pairs depict the metadata of an alert. i.e. the information about the source of origin of the alert (the system/ machine from where the alert was raised), the line where the machine is located etc.

Example – if the alert is raised from equipment 1 from line 2 then the container information would look like

Name Value

Equipement1 Line2

4. Logs tab : This tab is used to log the changes that have taken place on an alert. This information is

displayed in a table. The table has 3 columns which show the operation performed on the alert (say a status change), the date and time of the change and the user id of the user who was responsible for the change. This is important to track the lifecycle of the alert in the system by the different business users who can view the alert.

5. Comments tab : This tab is an important part of the Alert WatchList. Here, different users can enter various

comments about the selected alert. These comments are registered along with the timestamp (date and time) and the user id of the user who had made the entry. This is essential for different business users to be aware of the entire thread of comments that have been posted by other users who have worked upon the alert so as to have a clear picture as to what the current state of the alert is and what are the necessary actions to be taken upon it in the future. Comments cannot be added to alerts which are in the Acknowledged or Expired status.

3.4 Set Status of Alerts As soon as the alert is raised, it exists in the new status. The user can change the status of the alert to one of the states depicted in the state transition diagram. On clicking the Set Status button, a dropdown is seen with the possible list of statuses that the alert can be changed to. If the alert status is changed from New to In Process, it means that the alert is being processed (some action is being taken to resolve the issue which led to raising of the alert). If the alert status is changed to Acknowledged, it means that the alert has now been processed completely. This is done to intimate the business user/users of the status of the alerts and whether or not there needs to be some action taken on it depending upon the current status of the alert. This can be helpful in resolving some major issues that have taken place in the shop floor which had resulted in the raising of the alert.




Changing the Status of an alert

3.5 Deleting Alerts

As can be seen in the figure below, one or more alerts can be deleted from the WatchList screen. A confirmation dialog will pop up on clicking the delete button. On clicking yes, the alerts will be deleted.

Deleting of alerts is done so as to remove alerts that are no longer necessary in the system.

Deleting alerts

3.6 Alert Logs

Logs tab displays all the logs for a selected alert i.e. if the status of the alert is changed or if comments are added for the alert or if the alert is forwarded to different roles, the actions will be logged along with timestamp and the user responsible for the change.




Logs for alert

3.4 Adding comments for Alerts

The alert framework provides a feature to add comments for an alert. This is done so that when two or more users are responsible for processing an alert, their updates can be tracked here. The entire thread of comments is displayed along with the time and details of who has made the change.




Adding comments for alerts

3.5 Forward Alerts

Another action allowed on an alert is to forward the alert to different roles. On click of the Forward Alert button, the user is listed with a set of UME roles to which the alert can be forwarded to.One or multiple roles can be selected to be forwarded to.

On selecting the roles and clicking OK, a mail notification is sent to all the users who have that role. If the alert requires some action to be taken, the user will be prompted to take actions on the alert by followUpAction links.

This operation on the alerts can be very useful for business users in a way that if a certain team 1 /business line is responsible for processing a particular alert but cannot proceed without some information from another business line (team 2) then team 1 can simply forward the alert to the roles that the business team 2 members posses.

Once the information has been provided by team 2 the alert can be then forwarded back to team one for further processing.




Forward alert to roles

4 Alert CleanUp Rules Alert Framework provides a feature to clean up or delete the alerts which are no longer needed in the system. This is similar to the Message CleanUp rule that exists in MII.

Alerts can be deleted/cleaned up using the Alert CleanUp Rules screen under the group “Alerts and KPI” in the MII Menu. Operations available on the screen would be: 1. Create cleanup rule 2. Edit cleanup rule 3. Delete cleanup rule 4. Enable/Disable cleanup rule 5. Run cleanup rule

The screen is as shown below :




Alert CleanUp Rules screen

The clean up rules can be filtered based on the alert statuses as shown in the fig above. The table displays all the Alert Cleanup Rules that are created in the system. Below panel shows the details of the selected clean up rule.

The details are :

1. Name and Description of the Alert Clean Up Rule. 2. Alert path : indicates the file path of the alert object. The user can browse the alert objects in the workbench or simply

give a wildcard character (*) which indicates any alert can be chosen for clean up. Also, if an entire project is chosen as the alert path, then all the alerts under tha project will be cleaned up/deleted. Example : //*

3. Alerts Older than : Indicates that the alerts older than the specified hours qualify for deletion. 4. Status of the alert. 5. Severity of the alert. 6. Enabled : indicates that the clean up rule can be executed (run).

5 Alert Services Alert services are a part of the existing illuminator services. A new service mode called the “Alert” mode is used to perform operations on alerts.

Alert service would provide all the functionalities that are possible in the ‘Alert Watchlist’ admin screen i.e. view alerts, change alert status, delete alerts and forward alerts.

URL for alert service would be as follows:

http://:/XMII/Illuminator?Service=Alert&mode=& =

Example : http://localhost:50200/XMII/Illuminator?Service=Alert&mode=GetAlertDetails&AlertId=497978




Parameters would be according to the mode used. All these modes would perform an authorization check before giving the result. This check would verify whether the user has the role that is required to do the operation (roles are added as part of the alert definition.)

Modes available in Alert Service would be:

1. Modelist: This mode would list all the modes available in the alert service.

URL for this mode would be as follows: http://:/XMII/Illuminator?Service=Alert&mode=Modelist Example : http://localhost:50200/XMII/Illuminator?Service=Alert&mode=Modelist where parameter is mode.

2. GetAlerts: This mode would return all the alerts for the user.

User can also provide the Status for which alerts need to be returned. Status would be an optional parameter for this mode. Status names and integer values for an alert are 1. Open: integer value 0 2. In Process : integer value 1 3. Acknowledged : integer value 2 4. Expired : integer value 3

Example : http://localhost:50200/XMII/Illuminator?Service=Alert&mode=GetAlerts where parameters include mode and id (id being optional).

3. GetDetails: This mode would return the details of an alert for which the user would pass the alert id in the

query URL.

Example : http://localhost:50200/XMII/Illuminator?Service=Alert&mode=GetDetails&Id=497978 where parameters are mode and alert id.

4. SetStatus: This mode would be used to change status of alerts.

Example : http://localhost:50200/XMII/Illuminator?Service=Alert&mode=SetStatus&Id=497978&Status=1 Here, parameters are mode, alert id and status, where status = 1 implies that the status of the alert needs to be changed to “In Process” (1 is the numerical value for this status).

5. Delete: This mode would be used to delete the alerts.

Example : http://localhost:50200/XMII/Illuminator?Service=Alert&mode=Delete&Id=497978 where parameters include mode, and alert id (ids can be one or more separated by commas)

6. Forward: This mode would be used to forward alerts to other roles.

Example http://localhost:50200/XMII/Illuminator?Service=Alert&mode=Forward&Id=497978&Roles=TEST_XMII_MAIL where parameters include mode, alert id and roles to which the alert needs to be forwarded to.

http://localhost:50200/XMII/Illuminator?Service=Alert&mode=Modelisthttp://localhost:50200/XMII/Illuminator?Service=Alert&mode=GetAlertshttp://localhost:50200/XMII/Illuminator?Service=Alert&mode=GetDetails&Id=497978http://localhost:50200/XMII/Illuminator?Service=Alert&mode=SetStatus&Id=497978&Status=1http://localhost:50200/XMII/Illuminator?Service=Alert&mode=Delete&Id=497978http://localhost:50200/XMII/Illuminator?Service=Alert&mode=Forward&Id=497978&Roles=TEST_XMII_MAIL




6 Appendix

6.1 Icon library

The icons below are used to depict Alerts in various stages

Alert Object

Alert severities:

Medium

Low

High

Alert statuses:

New

In Process

Acknowledged

Expired

Alert Clean up rule statuses:

Disabled clean up rule

Enabled clean up rule

6.2 Frequently asked questions

1. Can the status of an alert be manually set to “Expired”?

No. A system job (Alert Expiration job) runs every one hour to check for expired alerts (expiration time exceeded) and sets the alert status to expired.

2. What if no roles are assigned to an alert at the time of defining the alert? Will those alerts be visible?

Alerts with no roles mapped to them can be viewed by all users irrespective of the roles he/she is entitled to.

Additionally, if a user has the role of a “Super Administrator” he/she will be able to view all the alerts irrespective of the roles mapped to the alert

3. What happens if the expiration time of an alert is defined as zero hours? An alert with an expiration time of zero hours will never get expired. However, the alert status can be changed in the alert watchlist screen like any other alert using the set status button.




4. How often does the “Alert Expiration Job” system job run? This job runs every 60 minutes to check for alerts which have expired.

5. Can an Alert Clean up rule be scheduled to run apart from manually clicking on the Run button?

Yes. Alert clean up rules are by default scheduled to run every one hour as defined by the “Cleanup Interval” property in the System Properties screen of the MII Menu.

Copyright

© Copyright 2012 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

SAP Q&A - MII Alert Framework Guide...MII Alert Framework Guide Page 9 of 28 Mail body : Consists of...

Documents

Transcript of SAP Q&A - MII Alert Framework Guide...MII Alert Framework Guide Page 9 of 28 Mail body : Consists of...