This integration can get alerts from SAP Solution Manager, and perform some actions back in SAP.
Because SAP is only able to push data to an external source, the integration is using the Pull interface to store alerts from SAP to Service Now
SAP Alerts are creating Events and the system go through the Event Management Process, matching event Rules and CI recognition rules to create Alerts, as explained here : Administers Event
The complete ServiceNow Event Management process documentation is available here : Tokyo IT Operations Management
Alert are created in Service Now. By default, a business rule is listening for any change on the alert. If a change is detected, Service Now is updating the SAP Solution Manager Alerts (see Service Now official Documentation related to Push interface for details: here)
This interface is not Mandatory, and the call back to Solution Manager is optional
The MID WebService Event Collector enables you to collect alerts sent from SAP Solution Manager utilizing event stream notification capabilities. The interface is running a push and a pull interface to interact directly with Solution Manager (see HomePage)
Ensure that you:
Role required: evt_mgmt_admin
JSON formatted event messages are sent from SAP Solution Manager. The MID Server transforms the collected alert messages by parsing them using the TransformEvents_SAPSolution Manager script include, located here: Event Management > Event Listener (Push) > Listener Transform Scripts.
In the Listener Transform Scripts page, click TransformEvents_SAPSolman .
The default format of the URL to push alert messages from SAP Solution Manager to the MID Server is http://<MID_Server_IP>:<MID_Web_Server_Port>/api/mid/em/inbound_event?Transform=TransformEvents_SAPSolman
Variable | Description |
---|---|
MID_Server_IP | IP address of the MID Web Server Extension |
MID_Web_Server_Port | Listening port of the MID Web Server Extension |
The following procedure describes the collection of JSON formatted event messages using basic authentication. For more information about supported authentication methods, see Configure the MID Web Server extension.
Connect to SAP GUI and enter transaction code “SM59”, create a new RFC with the corrects parameters
Important:
You must name the destination MID_EVENT_COLLECTOR2
SAP parameter | Value |
---|---|
Target HOST | Enter the name of the MID Server |
Service No | Enter the Listener Port on the MID Server |
Path Prefix | Enter the URL of the MID Server transform script = /api/mid/em/inbound_event?Transform=TransformEvents_SAPSolman |
Then, enter credentials defined in Service Now in the “logon and Security” tab of the RFC
New custom BADI Z_ALRT_REACTION_IMPL has been created and is stored in a workbench transport request PSMK900100
After installation, This RFC will be called by the new badi Z_ALRT_REACTION_IMPL to connect to Service Now.
To use the new Badi implementation method, the Third- Party Component must be enabled in the System Monitoring configuration.You need to enable the Third- Party forwarding and this can be done at different levels:
In our case, we will setup the Global level, but keep in mind that you can configure the alert reaction ONLY for a specific monitoring template.
To access System Monitoring configuration : run the “solman_setup” and Select Application Operations > Select System Monitoring
Select Step 2: Configure Infrastructure > Step 2.3: Default Settings
Jump to Step 5: Define Scope
You can assign the template to all the systems or choose one or more
Jump to Step 6: Setup Monitoring
Each time that MAI settings is changed, monitoring templates must be reactivated. The Setup Status will change to warning with “Reconfigured required “ , for all already configured systems. Assign (if new) the template and always press Apply and Activate
When ABAP jobs are finished, check that the “Assignment Status” is green.
Result : all the templates and active Alerts assigned to HS1 and NWP will now use the new forwarding method.
Field mapping has been built in ServiceNow to simplify maintenance. By default the mapping is made as follow :
SAP data | ServiceNow Field | Description |
---|---|---|
severity | severity | SAP is using number from 1 to 9 (more critical) |
message_key | message_key | SAP message group ID, messageGUID |
description | description | event description |
source | source | SAP system ID |
managed_object_type | type | type of object, HOST, INSTANCE … |
managed_object_name | node | name of the object |
node | resource | solution manager node name |
source instance | the event class has to match the connetor pull instance name. Is a concatenation of {SOURCE}_{CLIENT} | |
source | additional_info.sid | SAP system ID |
rating | additional_info.rating | color of the event in SAP |
resource | additional_info.mandant | SAP mandant |
time_of_event | time_of_event | SAP time of the event |
This connector is made to send information's back to SAP Solman.
Role required: evt_mgmt_admin
Open Service Now instance, navigate to Event Management > Event Connectors (Pull) > Connector Instance and click New.
Fill in the Connector Name, Description, as a connector definition choose “SAP_SolutionManager”. Enter the SAP Solman address in Host field and add Basic auth credential, corresponding to the SAP web service User.
Note: When adding bi-directional functionality for a Push connector, the Connector Instance name must match the Source Instance field of the event generated by that source. The “connector instance” field is a combination of the SID + “_” + Mandant
For example, the following event is generated by the instance source PSM_001. To be able to send information back, you have to name your Connector Instance “PSM_001”.
Variable to set in Connector Instance Values :
Name | Value |
---|---|
Client | This parameter is representing the client value in SAP, usually 001. |
Port | SAP Solman WebService Port, default is 8000 |
Each manual update of an alert is logged in the Update Queue table (em_connector_update_queue), and an event is sent back to SOLMAN using the Pull interface
The following table show the triggers used to update SOLMAN
Action in Service Now | Action in SOLMAN |
---|---|
Close the Alert | Confirm the alert in the Alert inbox, alert is removed |
Set alert in Maintenance mode | A comment is added in SOLMAN, adding a maintenance message |
UnSet alert in Maintenance mode | Comment is removed in SOLMAN |
Set alert in acknowledged mode | A comment is added in SOLMAN, adding a acknowledgement message |
UnSet alert in acknowledged mode | Comment is removed in SOLMAN |
The Update queue business rule on the Alert table identifies each manual update of the alert and updates the connector queue with these changes. By default, changes to all alert fields are tracked.
The Event Management - Queue connector processor schedule job dequeues alert changes and sends them to the MID Server. By default, this dequeue process is performed in batches of 1,000 alerts. You can configure this batch size using the evt_mgmt.max_update_source_records property.
Step 2: Configure Infrastructure > Step 2.3: Default Settings
1- First, Connect to system with SAP GUI on client 00
2- Use transaction strust
3- In Trust Manager, open “SSL Client”, import SSL certificate and SAVE
4- -use transaction smicm (to manage ICM, system to hadle HTTP and HTTPS clients)
5- In menu admin, select ICM → Exit HARD → GLOBAL . This will restart ICM module