Gerry

@Martyn Houghton I am showing my lack of knowledge here around our own service portal, but if a customer marks their own ticket resolved would it not be better for the system to take that as red and set the request status to resolved taking the SLA measurement there and then? If the service portal does not allow for this I would say that would be a far better feature to add, Gerry

Prathmesh, Thanks for the clarification. It snot something we currently have in our short term roadmap but it is something we would like to investigate. As of today, while chatbots are often referred to as AI technology, in truth they are not that intelligent and require a lot of programming/teaching and only handle very specific lines of questioning. The challenge with these types of systems is to make them friendly enough to teach so its not a full time job just maintaining the thing. One of the better ones I believe is powered by IBM Watson but you only need to sign up and look at the tools used to create a conversation paths to realise just how complicated even the most basic of system teaching is. I will ask some questions internally and find out what we have/have not considered so far. Gerry

@Martyn Houghton Interesting requirement. I guess this is an obvious question, but what happens if you enter a date/time that was before some SLA based event was fired? We have seen all sorts of problems with this when you have the idea of "running timers". If we were happy to forego the ability to see where we "currently" are in terms of SLA response then providing the resolution date/time would be a no-brainer, but as soon as you want those fancy running countdown timers and pre-breach evens, setting a past date no longer makes any sense - you cannot unwind time on an already run process. I think what would be better here is some kind of SLA override where you would have a specific action to change the resolution time - despite the fact that the process and/or timers are expressing something different. This comes down to how you would expect to report on this really - it sounds easy to just provide the ability to provide a past date/time but there are a whole bunch of complicated problems, mostly business process related that have nothing to do with product features or capabilities. I expect you will not get a simple response to this feature request Gerry

@Prathmesh Patel Would you care to expand on what you are trying to achieve, what kind of bots? are are talking about? Perhaps an example scenario or an explanation of what business problem your are trying to solve? Gerry

Hi Chris, I have started a closed conversation group discussion around GDPR related issues, if you want to join the conversation let me know.~ Gerry

@Michael Sharp Our systems are not immune to the unexpected, but we aim to minimise the unexpected always - but we don't get everything right. The strategy though is to have enough command over our systems that should we get something wrong we can fix it very quickly, thats what enables us to move forward quickly - in Agile terms it called "failing forwards". You might also like to know that from a platform point of view, when it comes to defects that have a material impact on production we do not even have a concept of logging a defect in the traditional sense - there is no concept of a queue or backlog, we fix it there and then, a fix generally includes the following steps: - Diagnose based on postmortem, we aim to understand the problem without the need to re-produce it With the understanding of the problem gained we do a code review and a code fix, and in parallel to this happening... We make a test case which fails on the current (pre-fix) code stream We then build and push to 'test' where our tests run and the new code is verified to pass And we loop around of we find any problem, either with the fix we applied or any other problem we inadvertently caused In the core code (C++) domain, once we fully understand the problem, we can be out to test with a fix often within 30 minutes or so. Our standard practice once all tests are passing on our test stream, is 24 hours on 'dev', 48 hours on 'beta' and then we push to live. This pipeline is continuously rolling most of the time and in practice we have multiple fixes per build too. We will also from time to time, maybe 4-5 times a year we might do a hot-fix where a very specific single code change is pushed straight into production, but thats a lot of hard work that is a far more manual process so we avoid this scenario at all costs. The one other thing we do is we never branch code into production, that means we *always* build from trunk and trunk is always buildable and releasable. If we do introduce a problem along the way we fix and push out rather than roll-back in almost every single case. So I hope you can see, we don't make any assumptions about the robustness of our platform but we take providing a high quality robust service very seriously. Gerry

A quick update. We have now identified the root cause of the problem which was a configuration problem that caused the configuration data content from being unavailable to our application services. This in its self should not have caused production systems to fail. However, this condition showed up another previously unknown problem. We have now identified this primary problem and are currently adding monitoring to these service for this particular condition so our systems will identify the problem automatically should it happen in the future. However, In the case of the secondary problem where the configuration information checksum data is unavailable the application servers were also throwing an error, this was a design issue as the code should have been far more graceful in its handling of this condition. As a result, we have now added code that will ensure that application services will give 8 hours of grace time should any configuration information be inaccessible. This was a problem waiting to happen as the condition and the subsequent behaviour was previously un-encountered and therefore unknown to us which means it would have caught us out at some point. The change will be verified, tested and rolled out into production over the next 72 hours ensuring that production instances will no longer be affected by our internal configuration services having a problem. You have to love continuous deployment and the speed with which we can identify, solve and release solutions. Once again our apologies for any impact caused, even though it was less that two minutes of down time, it still hurts our pride Gerry

@Michael Sharp The change was on the face of it an innocuous change to allow Etags to be served for configuration information, it should not have had any impact on production systems based on our assessment of the change before it was applied. Now the fact that it did have an impact is a problem because there is now something about the way our platform is functioning that we do not properly understand. We will of course now investigate this and determine why this happened and what we don't understand. The essence of the problem is this - each instance reads its internal configuration from one of two web services (we have two for redundancy) and for some reason the change effected our application codes ability to read its configuration data. Now this system is designed to be fault tolerant inasmuch as in the event of being unable to read configuration data, it should continue with the configuration data it already has in memory. Clearly this did not happen so actually this has highlighted another problem. Rest assured we will of course investigate, get to the bottom of why this is and of course do something about it. So I want to assure you, we do not make changes during production times without considering risk, we were not expecting any problems and for what ever reason we got that wrong this time so we can only apologise, but I would like to take this opportunity to say that we make many changes a week as we evolve and improve our service for our customers, we get it right almost all of the time, it is just when we do get it wrong its very visible. As a point of interest and of transparency I will post pack here with an update once we have done a post-mortem and figured out what went wrong. Gerry

@Alex8000 Hi Alex, Can I just pick up on your comment below... Looking at your instance I can see that you have only opted for "Community" support, which means there is no direct means for you to contact our support team or raise a ticket. We do not take inbound telephone calls in the first instance for any support issues - all customers who have direct access to our premier success support plan have an option to "Raise A Request" on their support page and we always return a call by telephone within 15 minutes where required. In your case you will see from yout support page (screen below) that you only have access to Community Support which means via the forum only and with no SLA commitment, we typically would not call you back for community support but would respond on the forum. I just wanted to clarify that point with you as your comment could be taken as Hornbill are offering bad support which I don't believe is the case. Please be aware of this in the future, we will do our best to support you via the community channels but this does not typically include any form of telephone support. Gerry

@DeadMeatGF We would only show Authentications that are HTTP Basic or HTTP Digest types, I will need to ask someone to look at this but people are on leave at the moment so I will have to post back in a week or so Gerry

As GDPR is ever closer I have created a club that offers a secure place for Hornbill users/customers to discuss GDPR related topics with each other as well as with the team at Hornbill. We are interested in ensuring our platform and applications are fully supportive of our customers initiatives to be GDPR compliant but understand there is a great deal of Fear, Uncertainty and Doubt about what this means to organisations and further more these discussions could be sensitive. For this reason I have created a closed club that only Hornbill Customers and Hornbill Staff are invited to participate in. My goal is to foster constructive shared conversations where we can discuss issues around GDPR where I hope we can draw a better collective understanding of what GDPR means in practice, as well as drivers for our product roadmaps moving forwards. If you want to join this closed club please IM myself (Gerry) and if you are an existing Hornbill customer I will add you to the group

Hi Chris, Thanks for the update. Well like most vendors we are trying to understand what GDPR really means, until now I have been avoiding knee jerk reactions developing features that *might* help our customers with GDPR compliance, it would be a terrible wast of time and effort to develop stuff "just in case" so we have been holding off on any actions around this until we are sure its going to be of any use. I appreciate that people are looking for quick "just in case" fixes, thats a very common theme at the moment but I am keen to make sure our development efforts are channeled into areas that are going to be useful to the majority of our customers. On the one hand I can see the merit in what you are asking for but I can also see how this will only solve one small and specific issue, thats why I asked the question about email, I would be very interested to know what Microsoft's official line on this would be, because I cannot see how that could solve a problem, what about links to personal data, or URL's that contain personal data as params, or attachments that contain personal data, what about if those attachments contain an image in a zip file. etc etc. GDPR compliance first and foremost will need to be managed by policy, locking down systems capabilities will only get an organisation a very small way along the journey. So I can confirm that what you are asking for would be possible to implement, but its not currently on our development agenda for the reasons stated above. Would love others to Chime In on this topic though... Gerry

@Lyonel Thats great news, thank you for letting us know. Our use of HTTP and browsers is very standard so we generally have a good handle on this stuff. Of course once we are behind a customers firewall we loose the ability to easily contribute to support issues that are customer network specific. It does not help when Microsoft have hidden away registry settings that only Microsoft Engineers know about I am glad you guys found the solution though, thanks very much for taking the time to post back the details on our community - I very much doubt you will be the only organisation to run into this little nugget .. Gerry

Hi Chris, In answer to your question, yes it would be possible to restrict specific capabilities such as pasting/posting images into a timeline BUT I would add caution to this, the intent behind GDPR is important but not even the policy makers are intending to cripple businesses. I have a rhetorical question on this, really as a point of interest. How would you solve this problem with e-mail? Gerry

Hi Mike, I do not know anyone specifically using Mimecast, I imagine there are customers that do though, perhaps someone will chime in. The question they are asking seems very odd though so I would go back to them and point them at this thread. Gerry

@Michael Sharp You mentioned you were unable to get hold of your account rep, can I ask who and how you tried to contact them? I ask because I just wanted to clarify with you - having looked up your instance support details I can see your organisation has not taken up any support options which means the support entitlement for your instance is community support only, there is no direct route to our support team. Of course if their is any service availability problem you do have direct access to our global 24x7x365 support team. You will find all of this information when you use our support point of entry here: https://www.hornbill.com/support/ Once you provide your specific details you would see page below ... The active support plan for your instance is shown where the red arrow is pointing. The support options available to you are shown in the red box. If there was any issues detected by the service availability check you would have an addtional option to contact our 24x7x365 support team. Regards Gerry

Hi Michael, Your account rep would not be available at this time in the UK. In answer to your question, all email comes out of a single IP address, we do not provide private IP's per instance, thats not how our network functions. It works more like a GMail or Office365 where email for all customers emanate from a number of known fixed IP addresses. [edit[] yes, the IP is static, however we do not guarantee that would always be the same IP address. Its a bad idea to lock down email traffic by IP address, instead you might want to suggest to your email provider that they use SPF to verify email is originating from domain authorised servers, thats the correct way to do things now days. Hope that helps Gerry

SPOTLIGHT: Secure Trust Bank has Enterprise Service Management Success A recent post on our community forums inspired me to follow up with one of our community members called Dan and write this article. I love it when our customers get value from what we do here at Hornbill, so when I read this comment I just had to find out more. I contacted Dan and asked if he would mind me quoting him and would he mind me asking a few questions that I could perhaps blog about, he very graciously agreed and this is what he told me. Can you give me a brief background of who you are and what your role is at Secure Trust Bank? What Service Desk tool was in place at STB before Hornbill Service Manager? What other service desk tools have you used in the past? How does Hornbill Service Manager compare? What was your first impression of Hornbill Service Manager? In the headline quote above you stated things have gone well, can you expand on that? Can you pick out three things that you love about Hornbill? If you had a magic wand, what is the one thing you would change about Hornbill right now? Is there anything else you would like to mention in relation to Hornbill? Hornbill is a platform that is designed to be used beyond IT and just as Dan has experienced within his own organisation, there is a natural and organic expansion of service management across all departments in an organisation that need to deliver service to their workforce. The tool alone is never the answer, but a fresh and innovative tool will speak for its self and can be a great catalyst to help drive innovation within an organisation. There are real and tangible cost benefits for any organisation deploying an ESM strategy, with Hornbill that process can be simple, organic and risk free. You can see the original community conversation that served as the catalyst for this blog article here: https://forums.hornbill.com/topic/10919-custom-expression-and-or/

I think that might be h_sys_groups, I know the name of the table might be counter-intuative so I could be wrong, but take a look there to start with Gerry

INTEGRATION: Hornbill Open Integration Approach When I first conceived our Hornbill Platform I knew that the key to being successful was the ease in which it could be made to interoperate with other systems. In theory, the Hornbill Platform could be used to implement pretty much any business application with its many capabilities. However, for now at least, we have chosen to focus our go-to-market efforts on Collaboration, Service Management and Customer Management application areas. Any business system needs to be able to “play nice” with other systems, and not only should it work well but it should be easy to achieve comprehensive levels of integration without complexity. First of all, a little integration history. All systems have some form of API, everyone knows that, but APIs are generally not interoperable. In the enterprise world for example, an attempt by a working group sponsored by Microsoft to create a standard for exchanging information was created called SOAP, using XML technologies, specifically XML Schema to describe the information structure being exchanged. SOAP was adopted by Microsoft and Java SDKs and so the dream of seamless interoperability was being sold to the enterprise developers. Truth is though, the standard was too flexible, and too verbose in its representation, a classic outcome of a committee driven approach to standardise something. With the flexibility came interoperability issues as different systems took different approaches to represent data within the confines of the standard and it became clear that SOAP actually was not going to deliver on the promise of solving interoperability issues, it was actually going to create just as many. Since then, web technologies have really taken hold while browsers have never natively supported XML, instead a simple data representation scheme known as JSON (JavaScript Object Notation) which, along with REST has become the defacto standard for implementing API’s simply because its compact, easier to read and browsers support it natively. There are many variations of these schemes as well as some obscure schemes that use things like ASN.1 or other serializations so the integration landscape is not without its challenges. Now while we wanted to do as much of the heavy lifting as possible in terms of integrations so our customers don’t have to (see our iBridge for example), we also recognise that there will always be that one thing that we did not think of, integrating two systems always requires what I call “glue code” which is simple code that transforms a message from one format to another. So early on we adopted a strategy of providing a fully open and documented API for the Hornbill Platform and an open source integration approach. Every integration we build outside of our “everything is done for you” schemes are built and published as open-source projects under the Hornbill Community License, all projects we create are made available to our customers on GitHub, we fully support and maintain these projects, although our customers are also free to fork these projects and make them their own too. Here are some of the projects we have published with a brief description of their purpose dotNetApiLib – a library that makes integrating any .NET application with Hornbill simple and intuitive goApiLib – a library that makes talking to the Hornbill Platform easy from the Go Programming Language pythonApiLib – a library to use the Hornbill Platform API’s with Python phpApiLib – a library to enable you to integrate with the Hornbill Platform API from PHP goSWRequestImport - Supportworks Request Import Tool for Hornbill Service Manager written in Go goServiceNowRequestImporter – Import requests from a Servicenow instance into Hornbill Service Manager goDbAssetImport – A tool written in Go to import assets from a database source into Hornbill Service Manager CMDB goDb2HContactImport – A tool written in Go to import contacts from a database source into Hornbill goDb2HUserImport – A tool written in Go to import user accounts from a database into Hornbill goAzure2UserImport – A tool written in Go to import user accounts from Azure AD to Hornbill goLDAPUserImport – A tool written in Go to import user accounts from an LDAP source rPowerBIHornbillDataSources - Data Source scripts written in “R” that enable Power BI to use the Hornbill Reporting and Trend Engine APIs as data sources SCOrchHornbillIntegration – Runbooks that allows Microsoft System Center Orchestrator to integrate with Hornbill goApiScheduler – A simple tool written in Go that can be used to schedule the invocation of Hornbill APIs goHornbillCleaner – A tool to clear down test data in a Hornbill instance powershellHornbillAPIModule – A module that enables you to easily interact with your Hornbill Instance We are committed to providing a rich and diverse set of tools and integrations to enable our customers to gain the maximum value from using Hornbill in their organisations. All systems should be built to be interoperable but not all systems are built by people that understand this – I am pleased to say that at Hornbill we truly do understand this and embrace the idea of integrating with anything.

@Dan Munns one of our expert techs is going to have a look at this in the next 2-3 weeks, we have a number of other things that need to be completed. This is what he said.. We don't have anything as yet to auto-import assets from a CSV. It wouldn't be overly complicated to knock one up though, using the existing code in the DB asset importer... There should be no reason why we can't write an XMLMC module in PowerShell too, we have some of the code already in the invokeXMLMC runbook I knocked up for the MSSCOrch content pack. Let me look in to how PoweShell modules work and I'll get back to you... Watch this space.. Gerry

@Dan Munns Ok you could possibly automate the upload by calling the same API as we do for the upload from within PowerShell I guess, I am not sure I have seen anyone do that but I am sure it would be possible in theory, the alternative would be for us to implement an importer script that looks on your network share for the file and imports it - I am sure we can help you one way or the other, I have asked the question internally, lets see what we can come up with Gerry

@Dan Munns In terms of an automated CSV import, how would you propose this works. Where does the CSV file come from? is it automatically generated? or are you generating it manually? Gerry

INTEGRATION: Integrating with Microsoft Power BI Although we provide powerful analytics, dashboards and reporting capabilities built into the Hornbill Platform, that capability only caters for reporting on data held within Hornbill. We know that customers often need to report across data sets from multiple systems which is where Business Intelligence tools come in. Many of our customers have requested integration with Microsoft Power BI Data Visualisation Tool, it’s a simple yet powerful tool that allows you to manipulate and visualize data sets, linking and cross-referencing multiple data sets, even data sets from different systems creating dashboards with drilldown capabilities. Microsoft has set a new benchmark in the BI space because not only is this tool powerful, there is a free edition and Pro subscriptions start at a mere $9.99/user/month which is not very expensive considering what you get for your money. We have created an integration between Hornbills Analytics Engine and Power BI which is essentially a data source provider to Power BI. The integration its self is developed in “R” and we have made this available as an open source project under the Hornbill Community License (HCL), the integration is provided completely free of charge, and we can even help you set it up if you need us to. The integration can be downloaded from our GitHub here You can find out more about this integration by watching the video attached to this post or by viewing our documentation here or searching our community forums If you have suggestions for other integrations with Hornbill please let us know, we are on a mission to be the most well connected Service Management and Business Collaboration platform on the planet!

INTEGRATION: Integration with HP Operations Orchestration In my last article in my integration series I talked about our integration with MS Orchestrator, and when investigating these tools we found another very similar tool called HP Operations Orchestration (or HP OO for short) which is described by Hewlett Packard as Enterprise-scale IT Automation. If you are not familiar with HP OO is very similar in concept to MS Orchestrator which I wrote about here, both have integrations, both have an orchestration capability, both use graphical representation of their flows/runbooks, both have the notion of content packs, both provide a console to (at least in theory) allow non-IT users to initiate flows/runbooks and check their run status etc. One difference though is while Microsoft Orchestrator is designed primarily around IT automation for the Microsoft platform, HP has more of a focus on heterogeneous environments with HP OO being able to run on either Windows or Linux. HP Offer a Community edition of their Open Orchestrator tool which is a free download and fully functional but you are restricted to running 500 flow invocations a month, if you need more you have to buy the commercial version of the tool. Just like Microsoft Orchestrator we found using HP OO a little clunky, we hired in a qualified consultant to help us get to grips with how to use it in order to develop our integrations. It is obviously a good tool, but it is not the most intuitive thing in the world to use, and actually in that regard the HP and Microsoft offerings are quite similar. Our integration effort was focused in two distinct areas, first of all we have created a content pack for HP OO that allows the automation of Hornbill for numerous Collaboration and Service Manager functions, this content pack is available to download free of charge from HP’s ITOM Marketplace so any customer that is using HP OO as an IT Automation Tool can now automate a number of actions in Hornbill for user account management, collaboration and service management. https://marketplace.saas.hpe.com/itom/content/hornbill-service-manager-and-collaboration-integration Secondly, we have created a seamless interface to be able to invoke Flows directly from our business process tool. After you have set up a connection to your HP OO instance, which by the way you can configure connections from Hornbill to any number of HP OO Instances, you can simply drag an integration node onto our BPM canvas, browse the HP OO content hierarchy select the flow you wish to invoke, there is absolutely no code to write and our BPM can even wait for the completed flow outcome before continuing so you can control business process flow based on the results of the orchestration outcome. I asked one of our partner organisations who has worked with HP products for many years what he thought about our integration approach and implementation, and this is what he said… "I've been working with HPE Service Manager for seven years, and integration with HPE OO has never been as easy as it now is with Hornbill Service Manager.” Henrik Brattlie (@BratItsm), Manag-E For customers who wish to use HP Operations Orchestration, we have made it very simple and accessible opening up a world of possibilities to automate IT work within the flow of your business processes in Hornbill.