Jump to content

DanielRi

Hornbill Product Specialists
  • Content Count

    219
  • Joined

  • Last visited

  • Days Won

    18

DanielRi last won the day on March 23 2018

DanielRi had the most liked content!

Community Reputation

61 Excellent

About DanielRi

  • Rank
    Product Specialist

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,669 profile views
  1. Thanks for the clarification. I'm not entirely convinced (yet) that the "Failed to Create User..." error is related to the failure to set the account status. I believe that where the utility is concerned, the creation of the user account and the setting of the status are separate actions (If you inspect the userCreate method call, account status does not feature in its inputs - https://api.hornbill.com/docs/admin/?op=userCreate). First the utility will create the account via "userCreate", and then make additional method calls (such as userProfileSet, userSetAccountStatus, etc,) to complete the exercise. The question is, is it trying the "userCreate" blindly, rather than checking for an existing user id first, and then moving onto the additional calls after as normal, or not bothering with the additional calls at all? Anyway, that aspect may be worth raising with Hornbill Support but before heading in that direction, are you able to confirm the version of the utility you're currently using? A few bells began to ring while typing the above (but now I've written it I'll leave it be ), and just checking the release notes I can see that prior to version 3.03, the user account status section was completely ignored when processing a user account. Versions of 3.03 or later have the fix. Thanks, Dan
  2. I'm not sure I fully understand the reference to "Pre-load", but before we talk about that, are you able to confirm whether the user "taxxxxx.xxxxxkh" exists in Hornbill, along with the accounts current status?
  3. Due to how the imports operate, there will be users created on the first run of this configuration. This means that we need to cover for that scenario and ensure the status is set on creation of a user (as well as on update of any existing user). Upon creation of a user, I believe the default status will be "active".
  4. Hi Martyn, thanks for your post. In relation to the two points you mention: 1) The utility tries to create the user if it did not already exists, i.e. was disabled many years ago. This is one of the principles that all of Hornbill's user import tools operate on. If the import does not find a matching user id, it believes the user does not exist and so will create it. Therefore, with an import configuration intended to manage the archiving of users, there will be a certain amount of redundant accounts imported the first time it's run. Perhaps there's an opportunity to refine your LDAP filter criteria to only focus on more recently disabled user objects? 2) Fails to update existing user to archived as currently active. Error: "User already exists with account status: active" I would double check that the status is indeed set to "archived" and ensure the action is set to "Create and Update". On a general note, is there a reason why you maintain disabled user objects in your AD long term? I hope that helps. Dan
  5. The defect described in this thread was resolved and the fix contained in Service Manager build 1392 which was released to live on November 29th. Detail: Catalog item not visible to a Co-Worker when their team is excluded but the user is included.
  6. Hi Dan, I've encountered the need to set a "due date" on several occasions during my work with customers. Essentially the need to set a target based on a specific event that is influencing the delivery of the work (e.g. end of the financial year, an audit deadline, or a new member of staff starting) - which is what I would understand as being "fluid" in your description i.e. the due date could be quite a strict deadline (unlikely to move) but the factor influencing the deadline can variable for each piece of work. The immediate benefit of such a feature would allow easy sorting of the request list but in terms of the performance and service delivery improvement I'd be interested to know what type of reports or metrics would be useful to you in relation to a "due date". At the very least I would expect there is a need to compare the time at which the request was "marked" with the due date target, and then set a 1 or 0 accordingly - representing whether this was marked within the due date, or exceeded the due date. Would you be able to elaborate further in this area, or is the need essentially the same as reporting on Service-Level-based targets? I'd also speculate that there should be restrictions when it comes to editing any existing due date on a request. Who is involved in managing and setting of due dates in your scenario? The concept of a due date is already under discussion by the Product team and I understand you may already have contributed in some conversations but it would be great to hear a few thoughts on the latter points RE: reporting and governance around amending a due date. Thanks, Dan
  7. Hi Steffen, I've added the BPM definitions for you to explore at your leisure. These are based on the "EXAMPLE Hornbill Service Request Process" which is shipped out-of-the box. The first definition below utilises two human tasks: example-hornbill-service-request-process-incorporating-manual-authorisation.bpm.txt This second definition ("v2") replaces the first human activity with a BPM email notification which automatically looks up the line manager of the customer. This second approach is dependent on user-manager relationships existing in your instance. example-hornbill-service-request-process-incorporating-manual-authorisation-v2.bpm.txt I hope that helps, Dan
  8. Hi Steffen, to add to Stevens description above, here's how that would be achieved: If Line Manager information is being stored against a user (typically populated through the user import) there is scope to replace the first human task with an automated email to the line manager as follows: Of course you can adjust the "on-Hold" behaviour to suit your particular scenario(s) too. Dan
  9. During the recent Hornbill Academy Webinar, there was interest in how to create a widget that would display all requests logged Vs those that had been resolved each day. This post illustrates how this can be done using Hornbill Advanced Analytics. When the sample period is of importance (daily, weekly, monthly etc.), a measure is typically the place to go. In essence, what we are looking to do in this example is create two measures and display them in the same widget. Creating the measures The first measure we are going to create is “No. tickets logged per day”. You will need to input the frequency of the measure as daily and ensure you are pulling data from the h_itsm_requests table. Our Date ranging column will need to contain h_datelogged as the measure needs to put the records into the right sample period based on when things were logged. The query where clause will be used to ensure we are only considering records we are interested in. This could simply be h_requesettype=”service request”. The second measure will be used to obtain the “No. tickets resolved per day”. In this case, we will use h_dateresolved in the Date Ranging column. In the Query Where Clause, you may want to use a specific statement to also ensure that only resolved or closed requests are included in the measure. If you don't wish to define this in your statement, the measure will extract all requests that contain a Date Resolved timestamp, regardless of their current status. For example, without definition, the measure could include any request that has been resolved and subsequently reopened, as this would contain a historical Date-Resolved timestamp. When creating your measure, it is important to identify what information you would like to extract from the system and define your Query Where Clause accordingly. Building the Widget Now that we have these two measures, we can now create our widget. A chart-type widget will be suitable for our needs and as we are going to be displaying information gathered by a measure, and we are interested in the sample period, our data type will be "Measured Samples". Multiple measures can be displayed by adding a new series. In our case, our first series will represent our “Requests logged” data (taken from our “No. tickets logged per day” measure) and our second will represent “Requests Resolved” (taken from “No. tickets resolved per day”). Does it Add Value? This widget provides three pieces of information, the volume of requests logged per day, the volume of requests resolved per day, and as these are being displayed together you can potentially get a rough idea of how many active calls you would typically expect to have at any one time. I hope that helps, Dan
  10. During the recent Hornbill Academy Webinar, there was interest in how to create a widget that would display all requests that were due to breach within the next hour. This post illustrates how this can be done using Hornbill Advanced Analytics. In this example, I'll focus on a resolution (fix) breach but the same approach could be applied to a response breach by amending the database column the widget is focusing on. The fix target is stored as a timestamp in h_itsm_requests.h_fixby and the response target can be found in h_itsm_requests.h_respondby. The Hornbill Application Entity Viewer can be used to explore all the tables in the Hornbill database further https://wiki.hornbill.com/index.php/Application_Entity_Viewer or as an alternative there is a h_itsm_requests quick reference available on the hornbill wiki: https://wiki.hornbill.com/index.php/Reporting Grabbing the Records: When starting out with any metric-building, its important to be clear in what records we want to see and how we are going to extract these. The requirement here is to identify a list of times that fall into the period of one-hour from NOW ("NOW" being whenever the widget refreshes). So we're working with a time period in the future and a time period that is also continually "moving" i.e. the datum is not fixed. In this situation, I turn to my faithful reference: https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html and end up with the following where clause: h_fixby BETWEEN NOW() AND DATE_ADD(NOW(),INTERVAL 1 HOUR) BETWEEN - allows me to set two boundaries NOW() - allows me to grab the current date/time in the form "YYYY-MM-DD HH:MM:SS" which will be used as my first boundary DATE_ ADD - is going to give me the ability to add a time value (interval) to a date. In this case I need NOW + 1 to use as my second boundary. The result being I get all records from h_itsm_requests where the h_fixby timestamp lies between NOW and NOW + 1. Displaying the Result If I wanted this information on a dashboard, I'd probably go for the Widget that can show me a list of data and for maximum flexibility use the custom sql query option. The full query would be as follows: select h_pk_reference AS Reference, h_fixby AS Resolve_By from h_itsm_requests WHERE h_fixby BETWEEN NOW() AND DATE_ADD(NOW(),INTERVAL 1 HOUR) - See image below. Does it add value? On a final note, in keeping with the Academy Webinar, we should ask if this Widget is going to add value. In my opinion, looking at what's going to breach in the next hour doesn't give much room to react, in fact it probably creates anxiety and unnecessary pressure which could impact performance and morale. You may want to consider a widget that will display what is due to breach tomorrow. Looking further ahead will perhaps give more chance to get on top of the situation. If you're finding that the desk is swamped by breaches, I'd ask whether your Service Level targets are realistic given the manpower, type of incident/request being dealt with, or quality of service you're aiming to provide the customer.
  11. Thank you to all that attended yesterdays Hornbill Academy Webinar "Winning with Analytics". It was great to see such a big turnout and I hope everyone found the content useful in some way. An hour is a very short space of time to talk about Analytics! There were a number of questions asked at the end of the webinar and unfortunately time was against us so I was unable to answer many of them. As promised, here is the follow up to those questions. "Will a recording of the session be made available to view again?" Yes, we will make the recording available to all those who attended the webinar. Details will be sent out soon. "Is there anyway to view a slideshow without having to log into admin console? As this makes it difficult to have a dashboard running on a display screen as a user needs to be left logged in on a separate session on the screen for it to run." Currently dashboards can't be published or distributed in any way. A slideshow must be run in the context of a user who has the appropriate roles to run the slideshow and access the data being show on the dashboard. Generally speaking, any action or operation performed in your instance is done in the context of a particular user. "When configuring a measure, what impact do the the "scorecard" and "sparkline" limits have?" The Scorecard and sparkline limit settings dictate how many samples are shown in the scorecard and in the sparkline graphics on the list of measures. We talked about sample history being the number of samples that would be stored in the system. There may be a situation where your sample history is quite large, say 180 samples (i.e. if you wanted to store 6 months worth of daily samples), however trying to display 180 scorecards or 180 points on the sparkline is probably not a good idea unless you've got a REALLY big monitor. It's partly an aesthetic consideration, and typically only the most recent samples are relevant for that at-a-glance trend the list of measures provide. When creating a measure, what is the function of the "Date Ranging Column2"? As we know, the date-ranging column defines the date/time field that determines the sample period the record (e.g. request) relates to. i.e. in the case of a measure that is sampling daily, do the records relate to Mon, Tues, Weds, or Thurs, etc. The Date Ranging Column2 allows us to set a second date/time field which is useful if we want to create measures such as "Incidents Logged and Resolved in the same day". In this example, you would set the first date ranging column to be "date logged", and the second date ranging column to use "date resolved". The measure would then only include a record for Monday if the date logged and date resolved both occurred on Monday. Widget Examples There were also a couple of questions asking how to create particular widgets. I'll cover these in separate posts. Dan
  12. Hi Alisha, thanks for your post. The logs can be found in Hornbill Administration via Home > System > Monitor > Monitor Log Files and this error will be logged in EspServerService.log The logs are only accessible by someone with the "Admin Role" security role and typically only show the activity for the current day (as they're archived when they reach a certain size). If you don't have permission to access the logs I would advise speaking with the person responsible for administering Hornbill as they will be the ones who have the access. Once you've found the error, please post it here and we will be able to offer further assistance. I hope that helps, Dan
  13. @Jeremy I think I understand what you're saying. I assume the progressive capture question is using a select box being driven by either a static list (configured in the pro cap field) or a dynamic list (located in Service Manager simple lists). Is that right? So you're suggesting that the decision was once using the "value" in its evaluation but now is using the "display name" in the evaluation and therefore failing to match the string "Windows 10"? Can you send a screen shot of the simple list or static list you're using and confirm my interpretation above? Thanks Dan
  14. @Jack_Podmore thanks for posting! As @HHH has said, these button labels can be changed by amending the appropriate translation string in Hornbill Administration > Home > Hornbill Service Manager > Translations . Every piece of text throughout the application has a translation string and as well as allowing us to display the term in German, French, etc we can also amend the English translation to use more appropriate terminology. When it comes to the portals, the strings you need will depend on what portal you're working with. As you might know, Hornbill Service Manager has two portals. The "Customer" portal facilitates external support and is used in conjunction with contacts whereas the "Service" portal is used to deliver a support function within your organisation and is accessed by Basic Users. Each portal has it's own set of translation strings: For the Customer portal, all translation strings begin with guest.com.hornbill.servicemanager.portals.portal....... For the Service portal, all translations begin with guest.com.hornbill.servicemanager.portals.servicePortal........ A very subtle difference, but one to be aware of. Therefore I believe the translation strings you're looking for are: guest.com.hornbill.servicemanager.portals.servicePortal.home.requestView.details.resolve.working and guest.com.hornbill.servicemanager.portals.servicePortal.home.requestView.details.resolve.broken I hope that helps! Dan
  15. @samwoo I think I may be able to offer some advice in relation to the errors you posted above: https://eurapi.hornbill.com//xmlmc//apps/com.hornbill.servicemanager/?method=shrGetCustomerDetails: invalid request :path "//xmlmc//apps/com.hornbill.servicemanager/?method=shrGetCustomerDetails" . When you see an error stating "invalid request path", this will be most likely due to an incorrect or missing instance name in the conf.json file. I would expect to see your instance name somewhere in the path as follows: https://eurapi.hornbill.com/<instanceName>/xmlmc//apps/com.hornbill.servicemanager/?method=shrGetCustomerDetails . The reason why it goes onto say "Create" even though you know the asset exists in Hornbill is because the utility could not complete the search in Hornbill due to the invalid path. Basically, the utility did not receive any results from the search to confirm that the asset already existed, therefore it assumed it needed to create a record. This can be seen here: "API Call failed when searching instance for existing Asset:Post https://eurapi.hornbill.com//xmlmc//data/?method=entityBrowseRecords: invalid request :path "//xmlmc//data/?method=entityBrowseRecords"" Specifying a valid instance name and API key in the conf file should address these particular errors. I hope that helps. Dan
×
×
  • Create New...