Jump to content

Search the Community

Showing results for tags 'integration'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Hornbill Platform and Applications
    • Announcements
    • Blog Article Discussions
    • General Non-Product Discussions
    • Application Beta Program
    • Collaboration
    • Employee Portal
    • Service Manager
    • Project Manager
    • Supplier Manager
    • Customer Manager
    • Document Manager
    • Configuration Manager
    • Timesheet Manager
    • Live Chat
    • Board Manager
    • Mobile Apps
    • System Administration
    • Integration Connectors, API & Webhooks
    • Performance Analytics
    • Hornbill Switch On & Implementation Questions
  • About the Forum
    • Announcements
    • Suggestions and Feedback
    • Problems and Questions
  • Gamers Club's Games
  • Gamers Club's LFT

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Organisation


Location


Interests


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype

Found 24 results

  1. Hi, In a test BPM I have set-up an iBridge (Cloud Automation) node to use an 'HTTP Request' to post to a Microsoft Teams channel when a Change Request is scheduled. The problem is that the 'Scheduled Start' & 'Scheduled End' date/time fields are being sent as UTC, not in BST. This is despite taking the advice in the WIKI to wrap any date/time field in 'square brackets' to get it to use the profiles regional settings. Anyone have any ideas? I did have an idea of pushing the two 'Scheduled' date/time fields to another two 'text' custom fields in the BPM and use these in 'BODY', but I dismissed this for two reasons. I wanted to maintain easy field management Also as the Scheduled date/times fields can be changed independently of the BPM at any time, I cannot always enforce updates to the custom fields. Thoughts anyone please? Thanks.
  2. Please can I request a Google Docs integration call to be added to the list of Hornbill Integrations. We would like the ability to create documents from requests passing fields inc custom fields, I am more than happy to discuss further if required.
  3. I am having problems with setting up a 'Cloud Automation' node to allow me to post to a Microsoft Teams channel. I am filling out the node and when I click the drop down arrow in the 'Team Group ID' field, I get the word "Loading' displayed then this error... I figure that I have to select the 'team Group ID' first to get the integration to connect to MS Teams to then pull back the available Channel IDs for that Team. I know what the Channel ID & Team Group ID is but I cannot add these to the fields manually and the node be happy with the inputs. Also, as per the red error message, how do I "check the console for more information"? The user defined in the Key to access Microsoft Teams has full Admin rights, so can't see that this is a permissions error. Thanks Steve.
  4. Is there a way once a spreadsheet has been updated that you can add further data to the end of a row? e.g. if we add data to a sheet from column A to E on one row as part of the BPM and then later want to add more data to column F & G later in the same row as part of the BPM...Is this possible?
  5. On Friday and over the weekend we have noticed that some (not all) requests that have integration calls were failing the integration type that we are using is: *Utilities/Experimental/HTTP Request - Basic Auth When they fail, we can restart the BPM once or twice and this then works. Have there been any issues at the Hornbill end? As we cannot immediately see any issues from our side....
  6. We are using the password generator to create passwords, however, some systems don't allow specific characters such as & or $ etc is there a way that we can have an option to disallow certain characters from being used in the password generation?
  7. We have an integration call that fails where the target does not receive the request, see below error When we check the sessions in the system we see the below, which seems to have multiple sessions for the same user. However we cannot see a reason for this happening.... does anyone know what is happening? There are ideas here around things like Service Manager updates happening for example, we had this issue this morning when we applied the latest update but we are not sure if this is a coincidence.
  8. Hi all, I'm trying to dynamically kick off change requests using the Hornbill api and using the logChangeRequest method, but in order for it to be logged correctly and the BPM to kick in I also need to feed it the expected answers from a progressive capture form. I've tried answering the questions using their field id within the "questions" param, however no matter which way I try to format them I get a FlowCode exception. I'm making the call within a PoSh script and have successfully logged Service Requests/Incidents, just this is currently giving me grief! Example params: $xmlmcParams = " <summary>$summary</summary> <description>$description</description> <requestType>Change Request</requestType> <teamId>STB/IT_#####/IT_#####/</teamId> <status>status.new</status> <sourceType>API</sourceType> <questions> <Question_1>Standard</Question_1> <Question_2>Low</Question_2> <Question_3>Standard process</Question_3> <Question_4>Low</Question_4> <Question_5>Standard process</Question_5> <Question_6>Roll back</Question_6> <Question_7>n/a</Question_7> </questions> <changeType>Standard</changeType>" Exception: FlowCode Exception (com.hornbill.servicemanager/entities/ChangeRequests/fc_ops/logChangeRequest): Input parameter validation error: The simple type value contains unexpected child elements at location &apos;/methodCall/params/questions&apos; Do I also need to supply the questionFieldMap param for this to work? If anyone has a working example of making a call which contains answers which would normally be fed from a prog capture that would be b e a u tiful.
  9. Hi all, We want to be able to post messages to our Microsoft Teams channels from within our BPMs and when setting up the Microsoft Key in the Keysafe, we are running into a 'security issue'. The first part of creating the key goes swimmingly, the issue comes when then clicking on the 'Connect' button. It correctly pops up the Microsoft window prompting for a user to login with. The issue is with the fact that the account that needs to login, needs 'Microsoft Admin level permissions' in order to proceed so that we can review the option we are authorising the Hornbill App to be allowed to perform. We do not feel like we should (nor do we want to) configure the Service Account (using a 'Service Account' as this is better for security) with Microsoft 'Admin' level permissions just to be able to post to a Teams channel. What permissions does the 'Service Account' need to allow this functionality to work, but still following the least privilege security principle? I don't know if this is one for you to answer @Steve G? At Insights19 you seemed to be the man that I'm sure would know the answers when it came to questions on integrations. Cheers Steve.
  10. Morning @Martyn Houghton @Dan Munns @Malcolm One of the questions on the Integration Round Table yesterday was: Can we write to a Hornbill Activity Stream (workspace) when a message has been added to a channel on Microsoft Teams? The answer is yes I've knocked up an example flow to demonstrate how that could work for you: You just need to replace the instance ID in the URI with that of your instance, the Authorization header needs a valid API key for an account that can write to the activity stream, and of course the activityStreamId in the body will need replacing with yours And this is what was written to the workspace in Hornbill: Note I'm using the HTML to Text node to strip out any HTML tags from the comment, as un-encoded HTML in the XML payload would cause the API call to fail. Hope this helps, Steve
  11. I thought I would post a quick preview of an upcoming feature of our business process tool. We are expanding its capability to include a new "Web Call" node. This new node will enable you to make calls to other systems or cloud services applications via restful API's which significantly expands your options for automation of business processes that need to interact with other systems. My goal as the architect for our platform technology has always been to keep the BPM 100% code free so that process managers do not have to have a programming background in order to make effective use of our BPM, but thats always a play-off, and this is one example where the absence of code limits absolute flexibility because there are so many different shapes and sizes of API's out there, code is the only "glue" that will give you ultimate flexibility. To solve that problem we are also developing an "API bridge" service that can contain and run glue code required while still keeping the BPM clean and code free for simpler day to day use. Once this feature is rolled out (expected to be in the next 2-3 weeks max) we will be exploring options for achieving the same for on-premise IT infrastructure and operations type orchestration and automation which I hope to be announcing in the coming weeks. This initial implementation is only the first step on our journey for much greater expansion of our BPM integration capability broadening our scope of IT Service Management into IT Operations Management for which there has been a significant demand for. Gerry
  12. Hi Just calling on the collected expertize of the community to help me get Atlassian Integration working. What i'm trying to do is use the Business Process and integration bridge to create a form/template that contains information that will be pushed to Jira. Something like this. Hornbill Request ID: (Taken from Flowcode variable) Steps to reproduce: (Here the Analyst fills in the steps necessary) Expected Result: (Here the Analyst fills in the info) Actual Result: (Here the Analyst fills in the info) The contents of the form would then be added to the Description Field in the Integration Parameters (see attached screenshot) First I just used the Description Flowcode Information but R&D blocked it since the quality of the created Jira was too low and they wanted something along the lines above. Any help is appreciated.
  13. Hi Is it possible to integrate with our on-premise active directory? I'd like to be able to configure catalogue items on self service that would automate amending AD security group membership. Suspect powershell would be required but not sure how to go about it (the powershell bits easy but how do we use it with Service Manager?). Can anyone provide any pointers/further reading? I've looked on the wiki and read the integration section but I'm none the wiser for it. Thanks J
  14. Hornbill iBridge for Linode Hornbill's iBridge is a great way to integrate with Linode, a cloud based solution for creating and managing virtual Linux servers. Between Hornbill's Keysafe and Linode's API Key a secure connection can be made between the two. Once done, you are able to use the Hornbill Business Process management for the orchestration of your Linode servers. Easily process requests from users requiring a linux server with a fully automated integration node. From a simple request submitted by a user, the Business Process workflow can automate the creation of a Linode server including the Data Center location, disk size, the image or distribution, root password, and the Linode plan to use. 
  15. Good Morning all, We have a printer service with Xerox, however they have their own call logging system that they like us to log calls to. Because of this we do not log the calls in Hornbill as we would then have to raise a separate email to Xerox to advise them of the issue, and because the 2 systems are not integrated together we would have to manually update the hornbill calls each time with the Xerox updates. We would also have to close the call in hornbill manually. What we want is to be able to create a call in hornbill that sends as email directly to Xerox. Then when they update we want them to send one back to us that goes into the ticket? Is this possible? if so what would I need to do? Hayley.
  16. Hi all, Probably something stupid I am (not) doing but after adding my Twilio credentials into the key safe I am unable to create an integration call in any BPMs. I select twilioSMS under method and then select sendsms but when I click apply it doesn't do anything. The window stays open like I didn't click anything so I cant save the config. As I am trying to generate text alerts based on Solarwinds emails I kind of need this to work. Also as we use Esendex as our SMS provider is there a way of integrating with them on the horizon? Thanks Dan
  17. 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.
  18. 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!
  19. 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.
  20. INTEGRATION: Integrating with Microsoft System Center Orchestrator In a previous article, I talked about Hornbills iBridge which is our solution for integrating with other cloud solutions.  The iBridge can also be used to integrate with some on premise systems too but as we build the integrations for the iBridge this is generally not flexible enough for most situations.  In order to integrate with systems behind an enterprise firewall we decided to look at what was already available and in use by our customers, this is where we found Microsoft System Center Orchestrator. For those of you who are not familiar with this tool, MSSC Orchestrator fits within the IT Operations Management market space and is a combination of an integration bridge and a flow orchestrator. Actually, to be honest the lines between these two things are a great deal more blurred in MSSC Orchestrator then they ought to be, but that’s a whole other article.  Integrations are connections that perform specific tasks on other systems, for example create a user account in AD is a good example. Once you have a number of these integrations they can be strung together as part of a flow which Microsoft call a “Runbook”, a name which comes from mainframe concepts in the 70’s.  As a customer, your IT teams can create integrations and runbooks to suit your specific business needs and exposed these through a unified interface that less technical business users can make use of (at least that’s the idea, not everyone gets this right). Creating integrations and runbooks in this tool is a fairly technical task and requires a good level of technical competence to undertake. In truth, Microsoft System Center Orchestrator has some serious flaws, we found it fairly difficult and clunky to use when working with it to create our content packs. The upside though, is it really supports Windows environments well with a lot of useful content packs out there ready to plug in and use, which is why we decided to include it in our integration strategy.   Anyway, to cut to the chase - we have created a seamless integration with Microsoft System Center Orchestrator making runbooks directly accessible from within our business process tool.  In fact; you can connect to any number of MSSC Orchestrator instances within your environment in a simple and secure way.  Once the connection is setup and established you can browse the content tree and use the RunBooks as automations in your business processes running on the Hornbill platform - point and click us and of course absolutely no coding required. Read More: Microsoft Orchestrator Integration In addition to being able to trigger runbooks from our BPM, if you are a Microsoft System Center Orchestrator user you can download and install the Hornbill Content Pack for Microsoft System Center Orchestrator which gives you a fully tested (and supported) set of ready-made runbooks that enable you to perform automated actions on Hornbill such as post to a workspace, log an incident, problem or change etc. Download: https://github.com/hornbill/SCOrchHornbillIntegration This capability is very empowering for our customers, from an integration point of view we are enabling our customers to orchestrate complex automations from within the Hornbill Business Process tool, with no programming expertise required. Not only that, because MS Orchestrator sits behind the enterprise firewall we are joining cloud and on-premise systems automation in a seamless and secure way.  At the time of writing this article our customers are already taking advantage of this capability and I look forward to hearing more great stories around this as they unfold.  
  21. INTEGRATION: Hornbill iBridge - Connecting the Cloud Following on from my previous post Not All Integrations/Automations Are Made Equal I want to share with you how we tackled the problem of esoteric and unmaintainable integrations for our customers.  I felt very strongly that non-technical business process users could easily use these integrations without the need to have a deep technical understanding of APIs, coding and authentication schemes. Hornbill has the ideal canvas in its business process tool, its an intuitive, graphical canvas that allows you to draw diagrams of your business process so Hornbill can orchestrate the flow for automated and human tasks. Expanding this capability to also be able to orchestrate automated tasks on other systems seemed like the next logical step for us to take.  Now as a general rule there are real technical challenges when trying to integrate with other systems. I am not going to go into too much detail here but I would like to highlight the key points. Most API’s now days on modern systems use HTTP as a transport for their API’s, this is a good thing.  However, this is also a very flexible, so while some use JSON as a payload, others use XML, some XML implementations are relatively simple and others are just ridiculously over-complicated for no good reason. (Yes Microsoft, you should be better than this).   Modern software systems like to call their APIs RESTFul which is supposed to be a simple alternative to things like XML-RPC and SOAP.  But every implementation is different, some use custom HTTP Verbs, others try to fit their business logic into some pre-defined standard verbs.  The bottom line is, every RESTful API is created with slightly different philosophical design approach. Interoperability is where things go very wrong.  Yes, XML, HTTP, SOAP, JSON are all “standards” but they are foundational standards, none of them tell you how to represent data for a given system, primarily because every system is different so these things have to be “glued together” Stateless or Stateful, yes this is yet another layer of complexity.  Some consider it to be more secure to establish and maintain a state (log in, keep session and log out when done) while others advocate stateless, for example using tokens or API keys. Authentication is probably the single biggest headache when building integrations, its security so by nature its complicated. There are many competing standards, which are also complicated, some examples are OAuth1, OAuth2, SAML, WS-Security, API Keys, Basic, Digest and a whole range of product-specific schemes too. Even worse, things like OAuth and SAML often require three phase authentication processes which need you to interact with the services own UI when trying to connect and authenticate. If you have ever tried to integrate with something yourself you will recognise some of these difficulties for sure. In order to solve these problems for our customers, we started by trying to understand what problems our customers have when trying to do this. We looked at the use cases for integration and we looked at many systems that have API’s to enable integration, we looked at tools that can integrate with other things and we looked at tools in the cloud that are specifically designed to integrate one thing with another thing.  In almost all cases there was a common theme, things get VERY technical VERY quickly, and almost exclusively there was the “get out of jail free” coding environment that one would need to use a lot!  There is no escaping the need for “glue code” when connecting systems together, when transforming messages and data from one system or another, the only real practical way is to use code, which left us with a dilemma, we either relax our “No Code in the BPM” policy and make our customers responsible for creating the glue code, or we take on the responsibility of creating the glue code ourselves so our customers don’t have to….  Care to guess which path we took...? Enter “Hornbill iBridge” (meaning Hornbill Integration Bridge), and it does pretty much what it says on the tin, it’s the bridge between our very powerful BPM tool and a large (and ever growing) number of pre-canned integrations ready to use.  The iBridge is a containing execution environment that hosts and runs our glue code, each and every integration has been built and tested by us.  Under the hood there is an integration development environment that allows us to rapidly build and test integrations.  The iBridge requires that integrations are exposed to the BPM in a business-friendly and non-technical way, and finally, the iBridge solves the problem of authentication. KeySafe is a new security feature of the Hornbill Platform that allows a complete de-coupling of security credentials and business process design. Imaginatively named based on the fact it’s a “Safe” place to store digital “Keys”. In essence, you can setup your credentials to the various systems you want to integrate with in KeySafe, giving each credential a name, within this environment you can do whatever two-phase or three phase authentication process is required by the service you are connected to, and once authenticated the credentials are safely locked away, encrypted, secure and safe. These keys can later be used within the BPM environment without ever exposing the details of the credentials.  KeySafe+iBrdige even handles the complications of refresh tokens completely automatically, logging every security even for full audit purposes. The Hornbill iBridge was introduced at our recent customer event Hornbill Insights 17 and because of our “Priced for Life” policy and commitment to customer loyalty, all existing customers get full access to the iBridge for free for as long as they remain a subscribing customer.  We have also opened up a community forum to take requests for new integrations which we have committed to build as we are keen to expand our integration portfolio.  As of right now we have over 400 built and tested integrations with 30 of the most common authentication scheme variations fully implemented and tested ready to use by our customers.  Here is our sticker portfolio of systems we have pre-built integrations for. You might have noticed from the above stickers, we have also committed to integrate with any system without commercial or competitive prejudice so we have even built integrations with competitive products including Jira, Servicenow, BMC, Freshservice, ZenDesk and Salesforce.  We have even built an integration with Hornbill so one Hornbill Customer can easily integrate with another Hornbill Customer instance if required.  One of the more exciting things our customers have reported is our integration into infrastructure and Tier 1 cloud solutions like Office365, Azure and Amazon Cloud making it possible for organisations using these services to automate provisioning of users, accounts and servers. Now these are big claims and I can understand why you might think that too, we have all heard this before, its never that easy right - well the best way I can think of convincing you is to show you some short videos so you can see for yourself how easy we have made this very complicated task, you can integrate with things in a few minutes without any technical expertise - watch and see for yourself... Integrate with Twitter Integrate with Slack Integrate with Trello Integrate with Servicenow Integrate with Microsoft Azure, Salesforce and Hornbill Integrate with Twillo SMS and Microsoft Azure We have only just got started with integration, we have a lot more to come so watch this space.  In my next article, I will be talking about our integration with Microsoft System Center Orchestrator for behind the firewall IT automation.    
  22. INTEGRATION: Business Application and IT Automation At the beginning of 2017 we decided to introduce a development theme to focus on IT and Business Systems automation.  As I was investigating what we needed to do I very quickly realised there was a lot of conflicting terminology so our starting point was to establish clear terminology around which we could anchor our internal conversations. If you are involved in product creation don’t under-estimate just how important this step is to get right, you will be surprised what seems so obvious actually isn’t. It turned out pretty quickly that we could not really consider automation without also considering Integration, while completely independent concepts, neither is practically deliverable without the other.  So, let me start giving you a simple 101 on that terminology and the context within which we interpret it. INTEGRATION: To connect two separate systems together in a meaningful way that allows one system to instruct the other system to perform a task or a function.  For example, if you want your service desk tool to send an e-mail message there needs to be an “integration” between your service desk tool and an email system that can deliver the message. AUTOMATION: Using an integration to initiate a task or function on another system at any given point in time. In the above integration example, a service desk tool that can send an email message might be described as – “The service desk tool will automatically send an email to the customer when the ticket is resolved.” – the ‘automatically’ being the automation of sending the email. ORCHESTRATION: Using a workflow to co-ordinate a sequence of automations in accordance with a pre-defined, and possibly contextually dynamic sequence in order to achieve a predictable and repeatable business outcome.  An example of this might be to create new user accounts on three decoupled and separate systems, but all orchestrated from one central point of control, triggered as part of a new employee business process. I was originally thinking about writing up our journey in great detail, but that all gets rather technical so I will refrain from the for now and tell you about the main business problems we as technologists wanted to solve for our customers. Pretty much every other system we looked at requires some level of “coding” to achieve integration.  Code is what “glues” two disparate systems together in a meaningful way, and while there are some tools that claim to allow you to do this, the truth is they all require you to code in one form or another.  We offer a 100% code-free customisable environment, especially in our graphical business process tool which is designed to be used entirely by non-technical people, so adding a simple WebCall node into our BPM (which is what pretty much every other system we looked at does), while would offer a level of integration capability would require the BPM designer to be exposed to some code in order to glue XML to JSON, or transform results from strings to integers and so on.  This was not acceptable so while we did create a WebCall node, we did not like it, so our solution needed to avoid raw web calls without making the integration capability too limiting.   We wanted to allow our customers to integrate with a wide range of other systems without the need to pay for a lot of expensive consultancy. Not to save on the consultancy bill its self, although that’s a nice side effect, it was more in recognition that when you pay for expensive technical expertise you end up being enslaved to their work, not because its bad work but because they are the only one who knows how it works, so when they are not available you are left holding the unwieldy baby. We don’t think that’s a good idea.   Aside from the programming aspects, the other very difficult thing to handle when integrating systems is “authentication”, while some are as easy as an API key, others require three-phase authentication and message signatures etc. like OAuth1a, not impossible to achieve in code obviously but as a general rule, way beyond the abilities of anyone that is not a proficient programmer and expert in the field.  All too often insecure systems are built because poorly hacked implementations of authentication schemes are implemented, or even worse the tool vendor gives you basic tools (like a scripting language) and leave the customer with the problem to solve.  Our view is, if it is complicated to do, then we should be looking to implement the complicated stuff under the hood and make it insanely simple for our customers to use.   We recognise that customers have integration needs for both cloud based systems (Office365, Salesforce, Amazon, Azure, Google etc.) as well as a need to integrate with, and automate their behind-the-firewall systems and applications, so whatever we came up with had to offer a solution here too.   We recognise that our customers need to integrate with, and automate a wide range of systems and tools, even tools that are competitive to our own solution, so our strategy needed to be open to any other system and not closed or restrictive in any way.   After six months in the works, we launched our strategy and a working set of solutions to our customers in June 2017 and I think we have delivered some really exceptional capability that meets all of the above. We offer, what in my opinion, is the best business process tool in the business. It is comprehensive, insanely powerful, but really simple to use, and in expanding that to include the Orchestration of Automations, I will go as far to say that we think we have done a better job at providing easy to use, code-free integration than pretty much every other comparable system we looked at.  Why? We thought differently about the problems we were trying to solve, coming at it from the BPM users point of view.  That is of course a bold claim, but one that is so for supported by the initial feedback from our customers. I would of course welcome any feedback both positive or negative, I know how everyone claims how amazing their particular tech is, so I invite you to follow this thread and judge for yourself. Now I have a lot to cover and if you got this far you are probably quite bored by now, so I am going to bring this post to an end.  But just before I do, I have listed the follow-up articles that I am going to write to continue telling this story.  As I write each article I will update this document with a link so check back every few days if you are interested in reading more. Not All Integrations Are Made Equal Hornbill iBridge - Integrating in the Cloud Integrating with Microsoft System Center Orchestrator Integrating with HP Operations Orchestration Integrating with Microsoft PowerBI Open Integration Approach
  23. I am working on a project to consolidate our organisations 'New Starter' process into one form/application and automate where possible. I obviously want the starting point to be the Portal, what options are there for integration into other applications?
  24. Did you know that we provide an ever expanding list of open-source tools for integrating and extending the Hornbill platform. We release these tools as open source tools under a very liberal open source licence (shown below). Our team here at Hornbill support many of these tools via our community channels and we encourage our customers and technology partners to get involved. These tools and examples provide a great resource for getting started with API/WebHook level integrations with our platform. All of these tools are open source and are freely available in source code from our GitHub repository. https://github.com/hornbill/ Please also see our integration page for more details and documentation on specific tools that are in common use. https://wiki.hornbill.com/index.php/Integration Gerry The Hornbill Community License (HCL) Copyright (c) 2015 Hornbill Technologies Ltd (https://hornbill.com) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: * The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. * Where this software is compiled into a stand-alone program the above Copyright notice shall be included in the programs published documentation and shown in any help or about text provided by the software at runtime and shall be visible to the end user of the program. * Where this software is used in any way whatsoever to provide a hosted or cloud based service, application, web service API or integration, the above copyright notice shall be included in the published documentation and shown in any help text or about box provided by the software and shall be visible to the end user. * The ELUA or, in the case of a SaaS or Hosted service, the Terms of Service agreement shall include the following statement: - Portions of this software Copyright (c) 2015 Hornbill Technologies Ltd (https://hornbill.com) THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
×
×
  • Create New...