Showing posts with label REST. Show all posts
Showing posts with label REST. Show all posts

Tuesday, February 11, 2020

Why you should use MXOSINCIDENT instead of OSLCINCIDENT for creating and querying ICD incidents

In re-reading the documentation and looking through the system, I finally recognized why the MXOSINCIDENT is a much better choice for integration than OSLCINCIDENT. The OSLCINCIDENT OSLC Resource only includes 11 attributes (fields) for an incident. Those are:

modifiedBy
modified
classStructureId
title
internalPrioirity
created
creator
priority
status
shortId
identifier


and that's it. So when you GET an incident via the OSLCINCIDENT URL (.../maximo/oslc/oslcincident/...), those are, essentially, all of the fields that you'll see for that incident. For example, here is the data I retrieved for incident number 1003 in my system:


dcterms:creator
rdf:resource "http://was.gulfsoft.rocks:80/maximo/oslc/os/sccdoslcperson/_TUFYQURNSU4-"
oslc:shortId "1003"
dcterms:title "First incident"
dcterms:created "2019-11-27T10:43:18-05:00"
dcterms:modified "2020-02-11T11:10:06-05:00"
sccd:statusdate "2019-11-27T10:43:18-05:00"
rdf:about "http://was.gulfsoft.rocks:80/maximo/oslc/os/oslcincident/_SU5DSURFTlQvMTAwMw--"
dcterms:identifier "9"
prefixes
sccd "http://jazz.net/ns/ism/helpdesk/sccd#"
rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
dcterms "http://purl.org/dc/terms/"
oslc "http://open-services.net/ns/core#"
_rowstamp "17235351"
oslc:modifiedBy
rdf:resource "http://was.gulfsoft.rocks:80/maximo/oslc/os/sccdoslcperson/_TUFYQURNSU4-"
sccd:status_description "New"
sccd:status
rdf:resource "http://was.gulfsoft.rocks:80/maximo/oslc/os/sccdoslcsyndomain/_SU5DSURFTlRTVEFUVVMvTkVXL35OVUxMfi9_TlVMTH4vfk5VTEx_L05FVw--"

However, here's the data retrieved for the SAME incident using the MXOSINCIDENT URL (.../maximo/oslc/os/mxosincident/...):


spi:ticketid "1003"
spi:status "NEW"
spi:pluspporeq false
spi:virtualenv false
spi:hasactivity false
spi:relatedtoglobal false
spi:changeby "MAXADMIN"
spi:accumulatedholdtime 0
spi:selfservsolaccess false
_rowstamp "17235351"
spi:class_description "Incident"
spi:inheritstatus false
relatedrecord_collectionref "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--/incidentrelrec"
multiassetlocci_collectionref "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--/incidentmultiassetloci"
spi:isknownerror false
spi:oncallautoassign false
spi:createdby "MAXADMIN"
spi:cinum "RBA_PAYROLL"
spi:statusdate "2019-11-27T10:43:18-05:00"
spi:affectedperson "MAXADMIN"
spi:class "INCIDENT"
spi:createwomulti "MULTI"
spi:description "First incident"
ticketspec_collectionref "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--/ticketspecclass"
spi:creationdate "2019-11-27T10:43:18-05:00"
spi:actlabhrs 0
spi:historyflag false
spi:sitevisit false
rdf:about "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--"
spi:createwomulti_description "Create Multi Records"
prefixes
rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
spi "http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#"
oslc "http://open-services.net/ns/core#"
spi:outageduration 0
spi:isglobal false
spi:multiassetlocci
0
localref "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--/incidentmultiassetloci/0-5"
spi:recordclass "INCIDENT"
spi:progress false
rdf:about "http://childkey#SU5DSURFTlQvTVVMVElBU1NFVExPQ0NJLzU-"
spi:langcode "EN"
spi:multiid 5
spi:isprimary true
spi:performmoveto false
prefixes
rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
spi "http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#"
oslc "http://open-services.net/ns/core#"
_rowstamp "17235352"
spi:hasld false
spi:pmchgassesment false
spi:recordkey "1003"
spi:cinum "RBA_PAYROLL"
spi:externalsystem_description "EVENT MANAGEMENT"
spi:pmscinvalid false
spi:reportdate "2019-11-27T10:43:18-05:00"
spi:hassolution false
spi:actlabcost 0
spi:changedate "2020-02-11T11:10:06-05:00"
spi:status_description "New"
spi:externalsystem "EVENTMANAGEMENT"
spi:affecteddate "2019-11-27T10:43:18-05:00"
spi:template false
spi:ticketuid 9
spi:reportedby "MAXADMIN"

To me, MXOSINCIDENT provides much better data.
Posted by at No comments:
Labels: , ,

Monday, December 2, 2019

Creating incident ticket in IBM Control Desk using the new REST API

Background

Maximo 7.6.0.2 introduced a new REST API that can be accessed via .../maximo/oslc . Here's a link to the documentation on it:

https://developer.ibm.com/static/site-id/155/maximodev/restguide/Maximo_Nextgen_REST_API.html

This is an all-JSON API that makes things a ton easier than it was with the older (and deprecated) XML-based REST API.

The Problem

However, that documentation is aimed at Maximo Enterprise Asset Management users and not IBM Control Desk users. That means there aren't any examples for creating incidents or service requests, for example.

Why You're Here

You want an example of creating an INCIDENT in ICD, and that's what I'll provide. I'm using ICD 7.6.1.1 on WebSphere, DB2 and IBM HTTP Server, along with the sample data. That's how I have a classification ID and hierarchy structure in the example below.

Basically, the best way I've found is to use the MXOSINCIDENT object structure because it already has a bunch of relationships (including one to TICKETSPEC, so you can add specifications when creating an incident). Here are the details:


Additional header:
properties: *

BODY:
{
    "reportedby": "MXINTADM",
    "description": "second MXINCIDENT OS API",
    "externalsystem": "EVENTMANAGEMENT",
    "classstructureid": "21010405",
    "ticketspec": [{"assetattrid": "computersystem_serialnumber","alnvalue": "99999"}]
}

RESPONSE:

{
    "affecteddate": "2019-11-29T15:02:00-05:00",
    "template": false,
    "creationdate": "2019-11-29T15:02:00-05:00",
    "hierarchypath": "21 \\ 2101 \\ 210104 \\ 21010405",
    "historyflag": false,
    "actlabcost": 0.0,
    "createwomulti_description": "Create Multi Records",
    "selfservsolaccess": false,
    "outageduration": 0.0,
    "ticketuid": 46,
    "inheritstatus": false,
    "reportdate": "2019-11-29T15:02:00-05:00",
    "class_description": "Incident",
    "description": "second MXINCIDENT OS API",
    "reportedby": "MXINTADM",
    "classificationid": "21010405",
    "sitevisit": false,
    "_rowstamp": "10009026",
    "accumulatedholdtime": 0.0,
    "createdby": "MXINTADM",
    "isknownerror": false,
    "affectedperson": "MXINTADM",
    "class": "INCIDENT",
    "ticketid": "1040",
    "ticketspec": [
        {
            "classstructureid": "21010405",
            "changeby": "MXINTADM",
            "changedate": "2019-11-29T15:02:00-05:00",
            "alnvalue": "99999",
            "mandatory": false,
            "refobjectname": "INCIDENT",
            "ticketspecid": 7,
            "assetattrid": "COMPUTERSYSTEM_SERIALNUMBER",
            "_rowstamp": "10009029",
            "refobjectid": 46,
            "displaysequence": 1,
        }
    ],
    "status_description": "New",
    "externalsystem_description": "EVENT MANAGEMENT",
    "classstructureid": "21010405",
    "changeby": "MXINTADM",
    "changedate": "2019-11-29T15:02:00-05:00",
    "externalsystem": "EVENTMANAGEMENT",
    "actlabhrs": 0.0,
    "relatedtoglobal": false,
    "hasactivity": false,
    "statusdate": "2019-11-29T15:02:00-05:00",
    "createwomulti": "MULTI",
    "hassolution": false,
    "virtualenv": false,
    "pluspporeq": false,
    "isglobal": false,
    "oncallautoassign": false,
    "pmscinvalid": false,
    "status": "NEW"
}

Prerequisites

To successfully do the above, you do need to Configure Object Structure security: https://www.ibm.com/support/pages/using-object-structure-security-limit-access-security-groups , and the user MUST have a Default Insert Site, which apparently my MXINTADM user does. MAXADMIN in my system DOES NOT, so it fails if I use that user.

I'm using Postman for testing, which I highly recommend: https://www.getpostman.com/downloads/

Of course you'll use some specific language (or curl) when you're doing this in production, but for testing, you want to use Postman.

A helpful link

In addition to the API documentation, this link was very helpful to me:


Posted by at No comments:
Labels: , , ,

Wednesday, January 16, 2019

Improving the QRadar to ServiceNow integration by adding QRadar event payloads to ServiceNow incident

Using the standard configuration for the QRadar/ServiceNow integration gives you some great capabilities, but some of our customers have asked for more information in the generated ServiceNow incidents. Specifically, they've asked to have the payloads from the events associated with the offense to be added to the Description of the incident in ServiceNow. This provides extensive details about the events that triggered the offense in one pane of glass so the SOC engineer doesn't have to separately open QRadar to get this information.

This can be accomplished my making some configuration changes in both QRadar and ServiceNow. I'll provide the overview here. If you would like more details, please contact me.

1. Add the offense start time to the incident description in the mapping within QRadar.
2. Create a ServiceNow business rule to parse the offense id and start time from the description whenever a new incident is created from QRadar.
3. In that same business rule, use the offense id, start time and a stop time (equal to start time +1) to submit an Ariel query to QRadar via REST to have the query run.
4. In that same business rule, parse the results of the previous REST call to get the results id, then make a second REST call to obtain the actual results, which will be the payloads of the events that caused the offense (and resulting incident) to be created.

The solution doesn't tax either system very much at all and makes life easier for the security engineer researching the issue.
Posted by at No comments:
Labels: , ,
Subscribe to: Posts (Atom)