iBridge Jira Integration

[Giuseppe Iannacone]

Could you please help out here on what has to be posted in the mandatory fields? i see no reference in the wiki or elsewhere.

we are using on Jira side:

- Jira Service Management Cloud

is this version supported by iBridge? is the method correct or is better to use the Jira Cloud method?

[Steve Giller]

@Giuseppe Iannacone Have you made use of the help flyout?

It probably won't answer all your questions but the nodes are fairly well documented without having to break out to the wiki.

 

[Steve G]

@Giuseppe Iannacone,

The Request Type and Service Desk fields are select lists, that will dynamically pull information from your Jira Service Management Cloud account when you click on the down arrow to the right of the input. Summary is as you would expect  

 

Cheers,

Steve

[Giuseppe Iannacone]

@Steve G & @Steve Giller
we were able to figure it out, now we want to bring further the integration with Jira, so we would like to test some API calls, the question is, which is the best practice for choosing a right user to create an API key against?
I mean, if i create an API key from my user, whith this key you can potentially do any action in my name (and with all my permission), right?
Also if we want to post update against timeline and requests, the API key should be linked to a licensed service manager user with right access to request type and services, right?

[Victor]

2 hours ago, Giuseppe Iannacone said:

which is the best practice for choosing a right user to create an API key against?

Think of whatever user would perform the actions manually. Update a request? Needs relevant roles to access the request. Update a service? Needs relevant roles to access the request. Etc. In summary, if the API post updates on request timelines then it needs a key for a user that has the relevant access to requests.

[Giuseppe Iannacone]

@Victor thank you, cristal clear!

[Giuseppe Iannacone]

@Steve G @Steve Giller @Victor
we are receiving this error message from api we used to test in our Jira integration
has something been changed on your side?

thanks

[Gerry]

@Giuseppe Iannacone

This error message comes about because when the API is being invoked you are specifying a different service endpoint in the POST URL than you have specified in the XMLMC payload. The following example would throw this exact message, because we are posting to the "automation" service (last part of the URL) but specifying the "session" service in the <methodCall service="session"> attribute

Gerry

POST /<your instance>/xmlmc/automation/
<methodCall service="session" method="userLogon">
	<params>
		<userId>admin</userId>
		<password>cGFzc3dvcmQ=</password>
	</params>
</methodCall>

[Steve G]

Hi @Giuseppe Iannacone,

Are you building and sending API calls from Jira back into Hornbill? If so, which Jira app are you using to implement this?

From your error message, it appears that you're using a JSON payload, which is not officially supported by Hornbill (yet). It works, but the JSON schema description is liable to change - as it did in the most recent release of the Hornbill platform. So I expect you are sending something like the following (from Gerry's XML example above):

{
	"methodCall": {
		"@service": "session",
		"@method": "userLogon",
		"params": {
			"userId": "admin",
			"password": "cGFzc3dvcmQ="
		}
	}
}

 When now you should be sending:

{
	"@service": "session",
	"@method": "getSessionDetails",
	"params": {
		"userId": "admin",
		"password": "cGFzc3dvcmQ="
	}
}

Note the lack of methodCall property in the second snippet.

Cheers,

Steve

[Giuseppe Iannacone]

@Gerry and @Steve G Thank you both.
I was not aware that the JSON payload is not officially supported. Our partner is using Jira (we have outsourced them a specific service) and we are implementing an integration with our instance.
do you suggest to use instead the xmlmc payload instead of the JSON one?

[Gerry]

@Giuseppe Iannacone

As of now, XML is the supported payload format for the API as it stands today.  JSON works (as you know), but its not officially supported because its currently implemented as a transform of XML, and therefore subject to XML Schema validation. The problem is, while JSON is currently accepted as valid input, the order of the properties inside an object presented is important today, this is fine technically, but wrong when you consider JSON being generated from a JavaScript object using something like JSON.stringify() where there is no guarantees of what order the properties inside an object will be serialised. It is for this reason that JSON is not officially supported for API request messages.  For API responses, JSON is fully supported without any issues.  

The problem you encountered above is because we have recently changed the structure of the JSON request message, to bring it in line with the JSON response structure, we made that decision because we assumed than no one was using JSON as we do not document it, or describe its use anywhere, and you will see if you look in the browser network tab and inspect the API calls from our front end, we always sent API requests in XML and get JSON responses. 

Now I have answered your question with a description because I am reluctant to just answer plain "Yes" to your question, and here is why.  You will see in the platform roadmap that we are working on a fairly big change around the API's, the primary objective is to transition our API implementations become JSON-first, that is, we will continue to support XML as we use today, but we will equally support JSON, and we will be transitioning all of our code to use JSON instead of XML over time. This work is in flight and the above change was one of the changes resulting from this work. 

So with the above explanation, the answer I can give you is... XML is the officially supported request payload because its 100% compliant with the XML Schema specification, and is currently our primary supported scheme.  JSON is 100% functional, and you can use it, but, when using JSON, you must be aware that the properties in the request object are required to be presented in a specific order because we effectively validate that input with the XML Schema validator.  Over the coming weeks, we will be transitioning our services over to a new scheme where JSON will be correctly supported with its own validation scheme, and so really in a matter of a small number of months I will be saying "use JSON"...

So my advice would be at this time, if you are using JSON for integration, and its working for you, continue to use JSON, but you will need to change the JSON request message payload to not include the methodCallResult top-level object as described above.  You can take this as an official statement that the JSON request format now is not going to change again, so it will be very safe for you to continue to use JSON without having any future issues, but as of today the documentation does not reflect this.
 
As I write this I realise this is not ideal, we are in flight with a change so we have to default our official position to what we know is not going to change, but in a few weeks time the answer will be very different and I want to make sure you take the best path. 

Hope this makes some sense.

Gerry

 

[Giuseppe Iannacone]

@Gerry thank you very much for this in deep explanation, I really appreciate it.
This level of details will sure guarantee us to take the right decision/path to follow.

Again Thank you.