Our take on Exstream after Dialogue

- Petrus and Vyv reflects

Little more than a week has passed since we came back from OpenText Dialogue 2016. Meanwhile, a hurricane had time to pass through the area where we were, and our impressions of Exstream have had time to sink in.

In summary it was a very successful conference. It felt like being back at the times with StreamServe before OpenText and Innovation Tour. That is, the focus of the conference was only on customer communications (CCM) and the product Exstream. Unfortunately, it sounded like this was the last Dialogue and that OpenText ahead imagines to90-procent-topp-prio integrate this conference with Innovation Tour and Enterprise World. In other words, the risk is that Exstream, jus as happened with StreamServe, will disappear in the mass of other OpenText products. On the other hand, with two strong products within CCM and a growing customer base, maybe there will be more space for CCM at Enterprise World. Especially considering that Mark Barrenechea mentioned customer experience (CX) and customer communication as one of the business leaders’ top 3 priority areas in the coming years.

mark-barrenecheaWe did not quite get the promised answer from Mark about how OpenText intends to deal with OpenText CCE (previously and in the following text called StreamServe) and Exstream. Apparently there is a clear agenda, but because of some minor details it could not be disclosed at Dialogue. Instead, it will be presented in conjunction with the release of Suite16 EP1 at the end of October. As for the third CCM player, Document Sciences Xpression, who entered the field in conjunction with the OpenText acquisition of EMC-Dell just before Dialogue there is a non-disclosure act in place until the purchase has been approved and completed. But what we brought back from the discussions on site with different representatives from OpenText is that StreamServe and Exstream will continue to live side by side, but that some underlying components will be coordinated to create a unified CCM architecture and platform within a couple of years. OpenText was also clear that the products have different focus areas and verticals. The StreamServe platform is to be recommended to Enterprise customers (that is customers using SAP) while Exstream is the platform for non-enterprise customers in verticals including Financial Services and Insurance, Healthcare, Telecom and Utilities. What this means in real life we hope will become more clear after the release of EP1!

How then is Exstream as a product and what are our first impressions as long time StreamServe users? Please note that the following is based on our subjective views after having spent limited time with Exstream during a hectic few days so there may be some inaccuracies for which we are solely responsible.

meeting people

First Exstream demo with Lies (Topdanmark), Mikael (OpenText Nordics) and Pinckney (OpenText).

The first thing that strikes us is how similar Exstream and StreamServe are in concept and execution. This is of course not surprising, in the end both products solve the same problem. It’s about triggering a process that captures a data stream, makes it presentable and then distributes the result.


OpenText Exstream architecture and main components.

One thing we liked was the basic architecture that makes a fairly clear distinction between design, data capture and delivery. In StreamServe these parts become more of an assembly composed in Design Center and then pretty much locked down.

Data capture in Exstream has a strength in terms of the ability to merge data from different sources into a common data model. In parts, this is also possible with StreamServe Storyteller from version 5.6.2 using Data templates. But our view is that the design choice made in StreamServe to put this inside the process and not at the event level, where we define the data model for the message, is bad. However, StreamServe has a strength in its implementation of XPath as the language for data access in the Storyteller. Exstream uses a model in which data is handled as variables, especially the access to repeated data is made with proprietary calls on arrays, a bit like msgGetValue() in StreamServe. In the latest release of Exstream it is possible to use XPath. But the implementation provides access to the entire incoming XML stream which makes it important for the developer to keep track of at what level he is because otherwise he may easily read the wrong data. StreamServe is less vulnerable because the XML available is only for the current document. Unfortunately, both StreamServe and Exstream has chosen to limit themselves to XPath 1.0, which means that many powerful features of XPath 2.0 is missing.


Exstream Designer with container based design. Print left, html e-mail to the right.

In the Exstreams design tool you may work with something called containers. In short, these are different views of how something should be presented. It can be a statement that could be delivered both as print and as html email. StreamServe would handle this as two different processes, one for paginated design (pdf/print) and one for unpaginated design (html). We enjoyed the possibility in Exstream to easily design for all formats side by side and to quickly preview the behavior of for instance a responsive e-mail within the visual tool.
We noticed a major difference between StreamServe and Exstream in the use of scripting. In StreamServe it’s not uncommon to script on an object and add logic for various properties: value, visibility, color etc. In Exstream this is instead done by opening a configuration window and visually put rules and logic for handling the object.


The equivalent of the Composition Center/Workshop-Storyboard is called Messagepoint.

The component in StreamServe to delegate management of content to the business through a web interface is called Composition Center or Workshop/Storyboard. In Exstream it’s called Messagepoint and is a cloud-based third-party product licensed by Exstream. A difference we see from StreamServe is the ability to have different life cycle and ownership of small parts of a document. For example, the customer service part of a bill, the financial part and the legal part. Each department handles only their content at in their own pace. If legal like to push out a change to the conditions on the invoice immediately they do not have to wait for the customer service to decide about their message.
Another part we saw in the Message Point and the we miss in StreamServe is a campaign management module for marketing messages.
A question is how Open Text will address that this is a product and service delivered through a third party? Given how central the functionality is and that OpenText at the bottom is a “content” company it’s perhaps not inconceivable that this is one of the components that will be coordinated between StreamServe and Exstream.


Equivalent to Adhoc/Retouch is called Empower.

Just as in StreamServe there is a possibility of working with interactive documents in Exstream. Previously Exstream only offered a thick client “Live” that had to be installed for each user. Nowadays Exstream also has Empower, which is a thin Web client just like Adhoc/Retouch for StreamServe. It’s perhaps unfair, given that the Retouch is far from a finished product and EP1 is around the corner, but in terms of interactive documents Empower already today handles basically all that we lack in StreamServe: ability to edit only single words in blocks of text, select the word / sentence from dropdown, using the input data in text, handle repeating data, update other text dynamically depending on choice in the previous text, upload or select additional resources in the form of images or PDF and insert into the document, send copies etc etc etc. And all this is done and updated directly on the document without need to reload. Neat and very user friendly!

One problem many customers have is to get a good insight into what is flowing through the system and how to handle any errors that may occur in different phases of the processing. StreamServe customers will most often, for lack of a standard solution, build their own tools for reading logs and notifications and respond to errors. In Exstream there is Command Center, a complete orchestration tool that handles reporting and control over the creation and delivery of communications. An interesting feature we saw was an integration between Exstream and Sparkpost for managing and tracking delivery of e-mail / SMS. There are pre-built routines to handle that if an e-mail is not received after X days then Command Center will distribute it as an ordinary letter.

Now that was a lot of text about this … In conclusion we can say that it was interesting to get a close look at Exstream and that as a partner of OpenText we look forward to helping our customers build functional solutions on this platform moving forward. Welcome to contact us if you want a closer discussion about OpenText Exstream.


Vyv and Petrus

Leave a Reply

Your email address will not be published. Required fields are marked *