SXI Forum

SeanR

Administrator

Registered: 20-11-2018

Posts: 148

Heat ITSM interface discussioin

When attempting to log an Incident into Heat ITSM we received a 'An item with the same key has already been added.'

This happens when the ProfileLink key was sent twice, that's why the API was unhappy. That, and CRNumber is not a valid key, although the request should still work, as the API will just ignore it.

Kevin: Will it be true to assume whenever an invalid field is passed to the API I would get this very same response?

Ruan: No, you'll get different error messages based on what is wrong, but these error messages might be misleading.

Kevin: You can telnet to confirm the SXI bridge to Heat ITSM is working:
    * I imagine I can get the server and port required from the config. Yes. It is 172.24.1.109 port 9752 - you can run the telnet directly from the 56 box.
    * When establishing the Telnet session is one expected to authenticate, if so how? No authentication needed. Simply copy and paste the string once connected and press Enter. You'll see an error message OR "Success - RecId: .........."
    * If so, how do I see the responses returned from the API. You'll have to look in C:\Program Files (x86)\Southern X Integrators\ItsmApiService\Logs directory on 172.24.1.109

    1. Does this Create(Incident) thing I am running always have the same key value pairs?

1. yes

Ruan: Great so once you get used to what is required you can begin to help yourself
what other kinds of "operations" can I make to the API, and where can I see what key value pairs those operations will require
27 mins

    1. Only Create (for incidents) and Update (For Worklog updates, and Tasks)

Create -> to create new calls
Update -> everything else
Table names we use:
Incident -> new call as well as status updates (Priority, ClientReferenceNumbers etc.)
Task -> To assign an already created call
Journal -> to add a worklog to an already created call
it's very primitive but effective
replied to your mail - let me know if there's anything else
Ruan: I see thanks a mil. So you run these transactions through the API but then you still need to that extra stuff I see you doing directly to the DB
to do that
19 mins

    1. for some operation types, yes. You see, Henk added additional columns to the Incident table after the API was developed, so if we try and populate those new columns, the API doesn't recognise the keys and simply ignore it. That's why I had to update the records manually afterwards with a direct SQL query...

it's terrible but it was the best we could do
Ruan •16 mins
No it is fine now that I understand it. Basically if I Create an Incident and someone says why didn't I populate a certain field it is probably because that certain field is something Henk added and I need to update that separately because the API does not know about that field

    1. That's right...
Ruan • 12 mins

Kevin: Just another thing I see there is some kind of trigger to allow us to update these "henk" fields which typically causes a collector to run and subsequently a provider. I imagine we could do this with a workflow and would not need that trigger
10 mins

    1. Yes again!

Ruan • 9 mins

Does the API return the reference number to the workflow to allow us to update the correct record from the workflow?
7 mins

    1. It returns a RecId, in the Response, If you look at the current BCXAfgriDCX Workflow, you'll see I've configured a condition to check the response, strip off all funnies before and after the RecID and lookup the IncidentNumber. You can copy and paste that if you like

i can email you the config if you want
Ruan • 4 mins
Excellent - the only thing is that trigger still runs I suppose to service all the collector/provider interfaces so somwhere in that DB we are going to have a table that has all thses signals in it that are not being used - not a problem we can turm that trigger off when all collector/provider are changed to workflow
4 mins

    1. oh ja it can be disabled easily