Jump to content

No longer able to log requests via API and PowerShell


Recommended Posts

Hello,

Our scripts to log requests just stopped working and I'm getting the following error:

Invoke-HB-XMLMC -XMLMCService "apps/com.hornbill.servicemanager/Requests" -XMLMCMethod "LogRequest"

Status Params Error                                                                                          
------ ------ -----                                                                                          
fail          The specified flowcode does not exist: com.hornbill.servicemanager/The type/Requests/LogRequest

This was working just fine before and it's just stopped working. Been using this for Scheduled Tasks for a long time without problems.

I have no idea what that error message really means. "The type" doesn't appear anywhere in any code.

I can query requests and log incidents against my instance just fine.

 

Link to post
Share on other sites

Thanks, that works.

Where can I read about these sort of changes to the API? Clearly it has not been case sensitive before as it's been working for a well over a year without changes.

That tells me someone did something in the API. Is there a changelog somewhere I can consult in the future for troubleshooting when things break?

I notice that in our PowerShell code we have the following

$uri      = "https://eurapi.hornbill.com/OURINSTANCE/xmlmc/apps/com.hornbill.servicemanager/Requests/?method=logRequest"

However in the template XML files for Scheduled Tasks this is the top line:

<methodCall service="apps/com.hornbill.servicemanager/Requests" method="LogRequest">

This process has always worked but must have broken sometime between 01.April and 01.May.

Link to post
Share on other sites

It's internally created; it's not an official template. The word template here is just used loosely to describe an XML file we created to create custom Scheduled Tasks by just replacing parameters like title and summary.

That doesn't really matter though; The point was that it's been working with "LogRequests" since sometime 2019 and just now sometime in the last 30 days it's broke.

I just fixed the capitalization in our XML files and it's now working again.

Link to post
Share on other sites

@Sindre Dreyer right, I had a chat with our team, trying to understand a bit more about this. You are correct in that there was a change in the last 30 days. In short, we are migrating our application metadata from Windows to Unix. As you might now, Unix is quite strict with capitalisation and that's where the issue stems from. We (our development teams) did check the code to ensure we avoid the issues that might arise from using incorrect capitalisations. As far as our tests go, everything works ok apart from certain areas that are still undergoing this migration (not related to this issue). Moreover we also implemented a failsafe mechanism to ensure any capitalisation mismatch won't stop the API execution. However, it appears this failsafe does not work as nicely as we intend it to work meaning it is possible for this mechanism to not fulfil its purpose, as you noticed in the log request failures you experienced. This is something developers are investigating now.

As for the issue itself, we are sorry for the troubles it has caused. Ideally the API usage should follow the documentation, including the capitalisation, but I fully understand this was not clearly mentioned there (documentation) with the added fact there was no indication from using the API itself that incorrect capitalisation is/will causing issues. Going forward I would say to ensure the capitalisation is correct and we will address the failsafe mechanism that did not work quite all right on this occasion.

Link to post
Share on other sites
18 hours ago, Victor said:

@Sindre Dreyer right, I had a chat with our team, trying to understand a bit more about this. You are correct in that there was a change in the last 30 days. In short, we are migrating our application metadata from Windows to Unix. As you might now, Unix is quite strict with capitalisation and that's where the issue stems from. We (our development teams) did check the code to ensure we avoid the issues that might arise from using incorrect capitalisations. As far as our tests go, everything works ok apart from certain areas that are still undergoing this migration (not related to this issue). Moreover we also implemented a failsafe mechanism to ensure any capitalisation mismatch won't stop the API execution. However, it appears this failsafe does not work as nicely as we intend it to work meaning it is possible for this mechanism to not fulfil its purpose, as you noticed in the log request failures you experienced. This is something developers are investigating now.

As for the issue itself, we are sorry for the troubles it has caused. Ideally the API usage should follow the documentation, including the capitalisation, but I fully understand this was not clearly mentioned there (documentation) with the added fact there was no indication from using the API itself that incorrect capitalisation is/will causing issues. Going forward I would say to ensure the capitalisation is correct and we will address the failsafe mechanism that did not work quite all right on this occasion.

Thanks for the explanation.

I don't really mind, these sort of things do happen, cost of doing IT.

But I would love if there was a change log or news page, or a version number increment on the API documentation that I could lookup just to see if any changes to the API has been made. Even if it wasn't an actual change-log but just a sentence "we've made changes at this date/time" then it would help me quickly identify if the problem was on our side or a change in API side and it would be faster to get it resolved :)

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...