Jump to content

API Scheduler not using named file


Recommended Posts

Hi all,

I am trying to get the scheduler to run a few .json files before I compile them into one big schedule.

The files are named for the task they are to create eg. 'ivr_reboot'

When I use the file switch the scheduler still calls config.json rather than the file I have specified.

Any ideas?

Thanks

Dan

Capture.JPG

Link to comment
Share on other sites

Hi @Dan Munns,

Great to see you using this tool, and I hope that you're finding it useful!

This was a defect in the utility, which I've just fixed and released v1.0.2 on our Github. The following is a link to the packaged release:

https://github.com/hornbill/goAPIScheduler/releases/download/1.0.2/goAPIScheduler_v1_0_2.zip

The documentation etc haven't changed, you just need to replace the executable with the one in the zip.

Let me know how you get on with this update.

Kind regards,

Steve

 

Link to comment
Share on other sites

Hi @Steve G,

Apologies for the lateness of my reply but the update works fine thanks.

 

One thing I was hoping for (and I know this will not be a top priority for you but is for me) is a way to make the Supportworks call import app target a specific call ref and import that only.

Ideally I would like it to run using a standard .json file but when you run it, the cmd window asks for the call number and then only imports that call (with attachments and all the other gubbins).

Having spoken to our Dev teams, they are unhappy that we are not importing 10 years worth of calls into Service Manager and have asked for a way to at least import some tickets should they be of value to their knowledge base.

Rightly or wrongly (I know which side I sit) they use Supportworks as a ticket management and information repository and don't want to move across without a way to import tickets on an ad hoc basis.

Apologies for going off topic.

 

Thanks

Dan

Link to comment
Share on other sites

Hi @Dan Munns,

Glad to hear the update to the scheduler worked for you.

With regards to the Supportworks request import tool, there would be a number of changes required to be made to the code to support this requirement. As well as changes to the logic, there are security concerns about sharing the tool in its existing state to end users (Devs, or no Devs :) ), as it currently uses a username and password within the config to create a Hornbill session, so this will need converting to use API keys for session creation too before you allow end users to use this. It's certainly all doable, but not a particularly quick change, so I'll add this request to my to-do list and will let you know when it's done.

In the mean time, it may not be ideal but it is possible to define specific requests to import in the SQL statements within the configuration file. So if your Dev teams could supply you with a list of requests that they want importing, then you could do this fairly quickly and on an ad-hoc basis.

Steve

Link to comment
Share on other sites

Hi @Steve G

Basically they want to be able to import relevant tickets from Supportworks as and when they find them. It will mainly be a case of:

New ticket is raised in Service Manager > Triaged and assigned to Dev team > Dev team look up fault history in Supportworks > Import relevant tickets into Service Manager > Resolve issue 

As at least one member of each Dev team has the admin role in Service Manager (and it will be them who import the tickets at the beginning) is there a way of us having the tool as described above until your API tool solution is ready?

We were supposed to be live with this software end of next week and this has just chucked a spanner in the works.

Is there also a 'free text search' function like we had in Supportworks as this is how they find old ticket information.

Thanks

Dan 

Link to comment
Share on other sites

  • 2 weeks later...

Hi @Dan Munns,

I've not had chance to rewrite the areas of the tool to cater for this specific requirement as yet, but in its current form your Dev Team Admins could use it to do what you need by each having their own copy of the tool and adding their own Hornbilll authentication details to the config file. And for each on the fly import they could just amend the request type specific "Import":true/false and "SQLStatement" parameters as appropriate (setting the Import parameter to true depending on the class of request being imported, and by adding AND opencall.callref = callreferencenumber to the relevant SQL Statement parameter).

It's unlikely that I will have any spare bandwidth in the next couple of months to work on updating the Supportworks importer to your specific requirements, but if I do then I'll certainly let you know once it's released.

With regards to the free-text search, the global search bar allows the searching of request data using Lucene expressions. This does not include timeline or historical diary entry data at this point in time, but we do have conversations ongoing internally as to how this could be implemented.

Kind regards,

Steve

Link to comment
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...