SXI Forum

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

Any Character can be used in XML using its Numerical Character Reference or (NCR). For example the Euro Sign € can be represented in XML as

€

If this causes problems with the Applications we are integrating with you can always use the Stylesheet Translate command to replace or remove them entirely.

This site has a list of all the NCR's

NCR Characters

When Tomcat is installed as a Windows service and the Java Version is changed the Tomcat service will not start.
Set Tomcat to see the latest version as follows:

Run ..\Program Files\Apache Software Foundation\Tomcat 9.0\bin\Tomcatxw.exe and then in the Java tab set the "Java Virtual Machine" to the new Java JVM path

If X-Notify service fails, the notification doc will go to the XmlError directory and does not get processed once the X-Notify service is restore.

Solution:

Create a batch file to run in X-Scheduler ever 5min or so.

Move_X-NotifyDocs.bat

@echo off
SET src_folder="X:\SXI\XPress\XmlError"
SET tar_folder="X:\SXI\XPress\XmlOut"
MOVE /Y %src_folder%\X-Notify~*.xml %tar_folder%
exit 0

I need to clear the SuccessStore and Exceptions list of files that are older than a week. What is the best way to do this?

This script relies on a utility called sc.exe and can be found here

REM
REM A trivial script to set ALL the XLayer services startup "automatic"

sc config X-Asset Client    start=auto
sc config X-EventCollector  start=auto
sc config X-FileTX          start=auto
sc config X-HBChecker       start=auto
sc config X-Notify          start=auto
sc config X-Scheduler       start=auto
sc config X-ServiceBroker   start=auto
sc config XPressDispatch    start=auto
sc config XPressStation     start=auto
pause

REM To adapt the script for setting the services "manual", change the "auto" to "demand"

How do you specify the field names in the DataDefinition when collecting data from a EXCEL file?

Goodday

Can I please ask your assist with an xpath to collect a ticket number written in memory from as a response.

Attached is an XPress document from a json string written to memory and our field of interest is the "display_value" tag

I am not sure how to pick that value.

Please assist

XPress doc

<?xml version="1.0" encoding="iso-8859-1"?>
<XServiceBroker xmlns="http://www.sxi.co.za/XMLSchema">
	<XHeader>
		<XPress>
			<Destination>127.0.0.1</Destination>
		</XPress>
		<XServiceBroker>
			<ActionName>Create</ActionName>
			<Provider>AddtoExist</Provider>
		</XServiceBroker>
	</XHeader>
	<ResponseMessage>
		<Object xmlns="">
			<import_set type="string">ISET0013048</import_set>
			<result class="array">
			<Element class="object">
			<display_name type="string">number</display_name>
			<display_value type="string">INC0068191</display_value>
			<record_link type="string">https://south32uat.service-now.com/api/now/table/incident/a949c7f1db716240ca53f1fabf961943</record_link>
			<status type="string">inserted</status>
			<sys_id type="string">a949c7f1db716240ca53f1fabf961943</sys_id>
			<table type="string">incident</table>
			<transform_map type="string">Event Management Incident</transform_map>
			</Element>
			</result>
			<staging_table type="string">u_event_mgmt</staging_table>
		</Object>
	</ResponseMessage>
</XServiceBroker>

This stylesheet removes namespaces from XML elements

<!-- Stylesheet to remove all namespaces from a document -->
<!-- NOTE: this will lead to attribute name clash, if an element contains
two attributes with same local name but different namespace prefix -->
<!-- Nodes that cannot have a namespace are copied as such -->

<!-- template to copy elements -->

<!-- template to copy attributes -->

<!-- template to copy the rest of the nodes -->

FieldDerivativeTables is a Global Rule, which means if enabled, this rule is applied to all the Fields in the configured Entrypoint.

For FieldDerivativeTables we need to do 2 things:

1. Configure the Rule

2. Enable the Rule

NOTE: It is strongly recommended that you use an intelligent XML Editor when editing all X-Layer configuration files.

SXI-approved XML Editors include Oxygen (requires paid license) and Microsoft Visual Studio Tools for Applications 2.0 (included in Visual Studio 2010. Also available by installing the ASP.net package on your machine).

Configuring FielDerivativeTables:

1. In the configuration, after the </Actions> element, create an <sxi:Tables> element (ignore this step if the configuration already contains an <sxi:Tables> element).

2. Inside the <sxi:Tables> element, create an <sxi:FieldDerivativeTables> element. (If you are using Oxygen to edit the config file, the rest of the required fields would have auto-populated). Remember to close the tag with </sxi:FieldDerivativeTables> if your XML Editor has not done so already.

3. Create the following inside <sxi:FieldDerivativeTables>, if your XML Editor have not done so already:

   <sxi:Match reference="">
   	<sxi:InputField name="">
   		<sxi:InputValue></sxi:InputValue>
   	</sxi:InputField>
   </sxi:Match>

4. The above simply enables us to first identify which fields in the transaction we want to match on. For example, if we have the following:

   <sxi:Match reference="Reference1">
   	<sxi:InputField name="Requestor">
   		<sxi:InputValue>Harry</sxi:InputValue>
   	</sxi:InputField>
   </sxi:Match>

5. "Match reference" is the "ID" of this specific match we are configuring. You can use any value here. We will be referencing it later.

6. "InputField name" is the ELEMENT or TAG NAME in the transaction that will contain the value we want to match on. Example: the TAG NAME of <User>Jane Doe</User> is "User".

7. "InputValue" is the value inside the above element to match. If multiple "InputValues" are configured then the rule will try to match any one of them. Example:

   <sxi:Match reference="Reference1">
   	<sxi:InputField name="Requestor">
   		<sxi:InputValue>Harry</sxi:InputValue>
   		<sxi:InputValue>Sally</sxi:InputValue>
   	</sxi:InputField>
   </sxi:Match>

8. We can also match as many fields as needed. For example:

   <sxi:Match reference="Reference1">
   	<sxi:InputField name="Requestor">
   		<sxi:InputValue>Harry</sxi:InputValue>
   		<sxi:InputValue>Sally</sxi:InputValue>
   	</sxi:InputField>
   	<sxi:InputField name="Company">
   		<sxi:InputValue>ABC</sxi:InputValue>
   	</sxi:InputField>
   </sxi:Match>

9. To summarize the the above configuration: We have a Match reference called "Reference1", which encapsulates the following conditions: IF the transaction contains an element name called "Requestor" with a value OF EITHER "Harry" or "Sally", AND an element name called "Company" which contains a value called "ABC", then we have a match!

10. You can create as many Match references as needed. Keep in mind that each Match Reference must have a unique ID (example: Reference1, Reference2, Reference3, etc.). Below is an example containing 2 Match references:

    <sxi:Match reference="Reference1">
    	<sxi:InputField name="Requestor">
    		<sxi:InputValue>Harry</sxi:InputValue>
    		<sxi:InputValue>Sally</sxi:InputValue>
    	</sxi:InputField>
    	<sxi:InputField name="Company">
    		<sxi:InputValue>ABC</sxi:InputValue>
    	</sxi:InputField>
    </sxi:Match>
    
    <sxi:Match reference="Reference2">
    	<sxi:InputField name="Requestor">
    		<sxi:InputValue>Peter</sxi:InputValue>
    	</sxi:InputField>
    	<sxi:InputField name="Company">
    		<sxi:InputValue>DEF</sxi:InputValue>
    	</sxi:InputField>
    </sxi:Match>

11. Now we need to tell the rule which modifications must be made if we have a match. Again, if your XML Editor has not already done so, create an element called <sxi:OutputReferences> after the last </sxi:Match> element. Remember to close the tag with </sxi:OutputReferences>.

12. Inside </sxi:OutputReferences>, create the following (only if it did not auto-populate already):

    <sxi:Reference name="">
    	<sxi:Fieldname name="">
    		<sxi:Output></sxi:Output>
    	</sxi:Fieldname>
    </sxi:Reference>

13. In the "Reference name" field, put in the NAME of the "Match Reference" we used earlier. In our example this would be "Reference1". Example:

    <sxi:Reference name="Reference1">
    	<sxi:Fieldname name="Department">
    		<sxi:Output>Sales</sxi:Output>
    	</sxi:Fieldname>
    </sxi:Reference>

14. "Fieldname name" is the NAME of a newly created OUTPUT Field we want to add to our transaction. In the above example we are creating an element name of <Department>.

15. "Output" is VALUE we want to assign to this new element. In our example this would mean that we have just created an element <Department> with a value of "Sales" ie. <Department>Sales</Department>.

16. You can assign multiple Fields and values per match, like below:

     
    <sxi:Reference name="Reference1">
    	<sxi:Fieldname name="Department">
    		<sxi:Output>Sales</sxi:Output>
    	</sxi:Fieldname>
    	<sxi:Fieldname name="Site">
    		<sxi:Output>Head Office</sxi:Output>
    	</sxi:Fieldname>
    	<sxi:Fieldname name="City">
    		<sxi:Output inputfield="yes">Location</sxi:Output>
    	</sxi:Fieldname>
    </sxi:Reference>

17. Look at the Output of the last field: <sxi:Output inputfield="yes">Location</sxi:Output>. inputfield="yes" means that we don't want to use a hard-coded value as output, but we want the rule to fetch the value of a specific element in the transaction instead. In the above example we are telling the rule to create a new element called <City>, and assigning the value of an existing element in the transaction called <Location> to <City>.

18. It is also possible to have multiple <sxi:Reference> elements, which should always match the amount of <sxi:Match reference> elements.

Enabling FieldDerivativeTables:

Now that we have configured the rule, we need to tell it when it should run. This is configured at Entrypoint level. In other words, it should be enabled for each Entrypoint where we want to run this rule.

1. Identify the Entrypoint(s) where the FieldDerivativeTables rule should run. Then, directly under the <sxi:EntryPoint name="..." source="..."> element, add the following:

   <sxi:GlobalRules>
   	<sxi:FieldDerivatives/>
   </sxi:GlobalRules>

2. We can also specify that the FieldDerivativeTables rule runs BEFORE any local rules (which apply only to individual fields) are processed:

   <sxi:GlobalRules>
   	<sxi:FieldDerivatives first="yes"></sxi:FieldDerivatives>
   </sxi:GlobalRules>

3. Below is an example Entrypoint configuration with an enabled FieldDerivateTables rule:

   <sxi:EntryPoint name="CreateIncident" source="d_serviceprovider_sd">
   	<sxi:GlobalRules>
   		<sxi:FieldDerivatives first="yes"></sxi:FieldDerivatives>
   	</sxi:GlobalRules>
   	<sxi:Fields>
   		<sxi:Field name="callnum">
   			<sxi:OutputField>TicketNumber</sxi:OutputField>
   		</sxi:Field>
   		<sxi:Field name="Assigned_Group">
   			<sxi:Rules>
   				<sxi:Default>Support</sxi:Default>
   			</sxi:Rules>
   			<sxi:OutputField>Assigned_Group</sxi:OutputField>
   		</sxi:Field>
   		<sxi:Field name="Name">
   			<sxi:OutputField>Name</sxi:OutputField>
   		</sxi:Field>
   		<sxi:Field name="Description">
   			<sxi:OutputField>Description</sxi:OutputField>
   		</sxi:Field>
   		<sxi:Field name="State">
   			<sxi:Rules>
   				<sxi:Default>Assigned</sxi:Default>
   			</sxi:Rules>
   			<sxi:OutputField>State</sxi:OutputField>
   		</sxi:Field>
   	</sxi:Fields>
   </sxi:EntryPoint>

READ THIS FIRST:

Self-signed certificates are helpful when a client uses an SSL web services connection to their integration partner (like BCX & BHP, Gijima & SolveDirect). When the certificate expires, the client does not always want to purchase a new certificate from a certification authority, but use a self-signed certificate instead in order to save costs.

Follow the 6 steps below to generate a self-signed certificate, and send the public one to the integration partner to implement on their side.

Normally self-signed certificates should only be used in development environments, but most of the time integration partners are running a dedicated IPSEC tunnel between them, so it should be safe to use.

Self-signed certificates are not advisable when the connection between partners are insecure.

1. Run the command below to generate a self-signed cert in an new empty keystore called tempks.jks (choose a new name for the keystore and fix the -dname to fit your URL):

   "C:\Program Files\Southern X Integrators\jre\bin\Keytool.exe" -genkey -keyalg RSA -alias selfsigned -keystore tempks.jks -storepass T@gi2b2 -validity 365 -keysize 2048  -dname "CN=webservice.MYDOMAIN.co.za,OU=MYCOMPANY, O=MY COMPANY (Pty) Ltd, L=Midrand, ST=Gauteng, C=ZA"

2. Use this newly generated keystore in the configserver.xml. The server.xml in the Tomcat config directory points to the keystore to be used.

3. Run the command below to export the certificate, which will be sent to the Integration Partner Company (file IntPartnr.cer):

   "C:\Program Files\Southern X Integrators\jre\bin\Keytool.exe" -export -alias selfsigned -file IntPartnr.cer -keystore tempks.jks

4. Restart the Apache TomCat service.

5. Then go to webservice.MYDOMAIN.co.za on an internet browser on the server where Tomcat is installed. You should get an error that the cert is not trusted. Import the Cert into the Trusted Root Certification Authorities store on that server. The reason for this is that Self-signed certificates by default gives this error and first has to be trusted.

6. Reconnect again to the above URL in the browser - It should now show that certificate is trusted.

Inventory collection tools provide Serial numbers for entities they discover. Occasionally these serial numbers are invalid and need to be actioned as they can result in duplicates on the CMDB. The REGEX to use to determine these invalid Serial Numbers is as follows:

^w+-1234567890$|^0123456789ABCDE$|^$|serial|^none$|^null$|^MUSTEK6376$|^MST6376$|^HMUFT$|^ESL$|^n/a$|^0+$|^na$|^FVSd$|^FVSdd$|^FVS$|^*+$|^1111TEST1111$|^1234567890$|^123456789$|^12345678$|^1234567$|^123456$|^12345$|^1234$|^123$|^12$|^1$|^0123456789$|^0123456789$|^012345678$|^01234567$|^0123456$|^012345$|^01234$|^0123$|^012$|^01$|^a$|^b$|^c$|^d$|^e$|^f$|^g$|^h$|^i$|^j$|^k$|^l$|^m$|^n$|^o$|^p$|^q$|^r$|^s$|^t$|^u$|^v$|^w$|^x$|^y$|^z$|12345|^OLKG74A18SI550$|^\';OLKG74A18SI550$|^23A0703$|TO BE FILLED BY|WHAT THE|FIC-0987654321ABCDEFGHIJ|REPLAB1|ŸŸŸŸŸ