It’s been quite a while since we issued our latest Feature Alert, being busy with several customer projects. But this doesn’t mean that we haven’t introduced new features, and in this Feature Alert, I’m going to run a review of selected new features and improvements we have worked on from September until the end of the year 2016.
New Feature: Developer-Friendly View for a Task
Extra for developers, we have introduced a second “view” of the integration flow (we call it also “task”) that they work with. This view enables them to see straightaway how to manage this particular task via API.
Another handy way of implementation of the so-called Developer view is when you work on a task from another environment and need to copy it to the main environment. Just imagine the following scenario: you have developed certain own integration components and tasks on our main, i.e. cloud-based instance. Now you need to move all of these onto another instance, e.g. to the one of your client. It’s quite easy and quick to push your components onto this other environment, but having to re-build the same tasks again means having to map everything anew from scratch manually.
With this new feature, all you need to do is copy the code under “Create a copy of this task”, and execute it via curl using command line. This way, the copy of the task will be created on the other instance within a few seconds.
NOTE: The target instance, on which you need the copy of the task in question, will have a different API key and might have a different email address to which it is attached to. Note that in your copy, you’ll need to replace these parts accordingly.
New Feature: Fixed component versions within integration flows
Since we introduced the versioning of components, we realized that while having the latest version of a component in an already running task automatically is a good thing in some cases, in other cases it is better to have rather a proven version than a new one. The reasons are many: a new version can contain a broken code, or a new syntax (especially if several people are working on it), or simply a new line of code. The result, though, is almost always the same: The whole task would stop working properly.
And so we decided that it makes more sense to allow developers to “freeze” the versions of the components used in a particular task. Let me give you an example.
Let’s say, you know that the latest version of the Demo component is the one you want to use in your integration flow right now, but you also know that your team will continue working on this component. So that their actions won’t affect your flow, you need to specify that this flow shall work only with the currently latest version until you decide it otherwise. In order to specify that, open the version picker first when designing a new task. By default, it is always set to the label “latest”:
Then select the latest version of the component you have. In the example below, the label “v9” and the label “latest” refer to one and the same version of the Demo component at the precise moment of the creation of the sample integration workflow. So, in order to prevent the component in the flow from self-updating, you need to select v9 so that the check mark appear against it:
Now, no matter how many versions of a component you and your team created after you took the Demo component to set up an integration flow, this flow (or “task”) will use only the version that it was created with initially.
This is a huge change that ensures your tasks won’t break because someone has changed one line in a component’s code. This is especially important if you use components that are provided by other parties, e.g. by elastic.io, since you cannot control when those components will be updated, and how.
And if you decide that the currently latest version of your component(-s) is finally ready to do some heavy lifting, you can easily make the necessary changes by opening the flow, selecting the right version, setting it up accordingly and starting the flow anew. For some more information and screenshots, please have a look at this article in our Documentation.
New Feature: Wizard for elastic.io On-Premise Installation
While it has been possible from the very beginning, deploying an instance of elastic.io on-premise was quite a time-intensive and complex procedure. Now we have a new Installer app that considerably simplifies this process.
With this new Installer for on-premise deployment, a fully-functional instance of elastic.io is installed on-premise within a few hours, as opposed to several days as it was previously the case. This new Installer does a large part of the work for you, automating the on-premise installation process to the large extent.
Additionally, such an elastic.io instance already has a number of built-in integration components such as Salesforce, Mapper, Webhook, which will be installed on-premise together with the platform, enabling you and your developers to start building integration flows immediately after the elastic.io platform is installed on-premise.
New Feature: Built-In File Storage
This new feature has a direct connection to the previous one, and it adds up to the data security levels as well as the speed of deployment that we ensure for our clients.
Previously, we used to use Amazon S3 to store our logs and a number of integration components. While there is nothing unusual for a cloud product to make use of external cloud services, it got a bit awkward when we were talking about an on-premise installation of elastic.io.
This was the reason why we decided to store everything either on our own servers (for our cloud-based installations) or at the customer’s “place”, i.e. on-premise (for elastic.io on-premise installations). Due to that, we have introduced a few new local services. For one, we now have a component storage that is built into the platform. This component storage means, for example, that if you use an on-premise instance of the elastic.io, all your integration components will be stored on-premise as well. The same applies to logs and any other possible files.
To sum it up, nothing leaves now the platform except for the cases when it has to communicate with external servers, e.g. when you make a call to Salesforce.
New API: The elastic.io Integration API v.2 is open for testing
Some of you might have already noticed that at the moment, we have two Integration API documentations. And the reason for this is that we have spent the past few months working on a new version of our Integration API. It is still in beta for the time being, but it can already be found together with the version 1 under the link https://api.elastic.io/docs/ and tested.
The new Integration API v.2 reflects all the experience and feedback that we have gathered since the release of the first version in 2015. For one, our new Integration API follows the standards of the json specification, which is widely implemented and accepted within the IT industry. Thanks to that, it will be by default compatible with a large number of various frameworks, libraries, etc, which allows for an effortless interoperability between languages and libraries.
Other improvements include, for example, more resources, higher flexibility, as well as more functionalities which we have already had in the frontend but not in the Integration API v.1.
The official release of the Integration API v.2 is planned in February 2017.
Further Improvements & Enhancements
Real-Time Flows now start even faster
Traditionally, all our flows needed some time to warm up a bit, and real-time flows were no exception either. Now thanks to a few improvements to how real-time flows work, the warm-up phase at the start of the real-time flows is skipped. For developers this means that the first data starts moving back and forth at the very moment of the activation of real-time flows.
XML support via webhooks
Our webhooks now support not only JSON, but XML payload as well. For more details refer to the Documentations article “Getting XML data into the elastic.io”.
Improvement of teams and organizations management
This is just a minor usability improvement. Actually, the process hasn’t changed a bit: Neither before nor now is it possible to invite to your team the people who are not in your organization. However, previously the UX would give you a misleading impression that it was possible by offering you to send an invitation email to the email address of your collaborators.
After hearing feedback of our clients and platform testers, we solved this issue by removing this bar for email addresses and replacing it with a drop-down bar, where you’ll find only the people who are already part of your organization.
What to expect in the coming weeks
Currently, we are working on a huge update of how elastic.io looks and feels. Yes, that’s right: There will be some big changes to the elastic.io interface. It will become more user-friendly and more intuitive, and it will look very different from what it looks now.
Another new improvement will include introducing versioning of tasks (yes, this time tasks, not components), which will enable developers to experiment with various setups more freely, while at the same time being able to define that only one particular (functioning) task is active at this precise moment.
We will also continue on enhancing our webhooks. Next step here – attachments support.
Stay tuned for more info;-)