/ Management  

Grab your details on the Brava! content viewer

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

In this post we do a deep dive into the Brava! software that brings content viewing to a next step. What the software is capable of can be read on the OpenText Brava! product page. What we will do in this post is just checking out the preview panel that shows content with/without Brava! to get notice of the differences. After that we do a Brava! installation and see the value that is brought to the platform and how Brava! is handling the content in its own unique way.

Bring your diving suit, flippers, snorkeling equipment and…


Let get right into it…

Spin up the VM machine and start in your project with the ‘awdev’ account. We continue with the previous post where we already created something nice to view content. So, what I recommend you to do is following that previous post ‘How to layout metadata with content side by side’ or craft something nice yourself where you are able to upload content via the ‘File’ BB in a nice layout. This is my starting point in runtime (that’s a preview without Brava!):

brava_001

Let’s do a technical view on that preview panel with the developer tools in Chrome via <F12> and when we dive deep enough you will see that this view is based on an iframe HTML element that loads a URL like this:

http://192.168.56.107:8080/home/appworks_tips/app/entityRestService/Items(0800273bf379a1eb821dbf683ae8091a.20)/ContentStream

brava_002

You first see 3 row elements that is the ‘Breadcrumb’, ‘Actionbar’ and finally the row that represents that metadata/preview panel structure with 2 column elements in it. The first column is our metadata form, and the right column is our ‘previewContent’ element that triggers the iframe URL. You see already the reference for ‘bravaFrame’, but this view isn’t a ‘real’ Brava! view (yet!)

If it’s not a real Brava! view, what viewer is used to show the content at this moment? Well, that’s the responsibility of the software that is installed on your local machine together with the browser that supports an inline view with that software part. In my case it’s a PDF document that can be viewed by any default browsers these days. That is the same case for simple text files, but it’s another case when you upload a more advanced file like a ‘Word’ document. Let’s do an upload of a Word file (.docx) and see the result that we want to avoid:

brava_003

That last error brings us to the next step…


The installation of Brava!

Our downloaded platform suite package is delivered with a folder called ‘OpenTextBrava’ and in there we have a ‘README’ file that globally describes these steps for installing Brava!

  1. A link to the Brava! documentation (that we might need later): https://knowledge.opentext.com/knowledge/llisapi.dll/open/58803561
  2. Install a Tomcat instance (I will run it on the same VM on port 8282; TomEE runs on 8080 and Tomcat for OTDS is running on 8181)
  3. Update the bravaInstall.properties
  4. Run the installer via: sudo ./installBrava.sh
  5. Optional: Add a ‘real’ license; the installer is delivered with a 30-day evaluation license.
  6. Run the publisher job via: /bin/publisher start
  7. Deploy Brava! app, but this is done by default already
  8. Restart Tomcat

Let’s follow those steps…

Documentation

Go to the documentation of your version (in my case this url) where the ‘Administration guides’ section is the most interesting, but this post will give you a great head start already!

From a previous installation I know that version 20.3 of the platform is delivered with Brava! version 16.6.2 build 20.0.0.72

Tomcat

For this we fall back to a previous post on Tomcat that we did to serve OTDS to the end-users. We just follow that post with this change in mind where we edit the server.xml: sudo vi /opt/tomcat_brava/latest/conf/server.xml

Keep in mind that I use ‘_brava’ as postfix for this installation in the path variables.

1
2
3
4
5
6
7
<Server port="8007" shutdown="SHUTDOWN"> <!-- was 8005 -->
...
<Connector port="8282" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8445" /> <!-- was 8080 and 8443 -->
...
<Connector port="8445" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true"> <!-- was 8443 -->
...
<Connector port="8011" protocol="AJP/1.3" redirectPort="8445" /> <!-- was 8009 and 8443 -->

The Tomcat version 8.5.43 in that post will be fine as the Brava! release notes tell us to run Java OpenJDK 11/13 with a Servlet 3.1/4.0 API support…Well, lucky for us:

brava_004

Update bravaInstall.properties

Now it’s time to upload the ‘OpenTextBrava’ folder of the installation package to the VM. We can easily do this action via MobaXTerm where we have a session open with the ‘otadmin’ user. Just drop it in the /home/otadmin directory!

These are the updates we need to do in the properties file: vi ~/OpenTextBrava/bravaInstall.properties

1
2
3
4
5
6
7
...
webAppDir=/opt/tomcat_brava/apache-tomcat-8.5.43/webapps
...
bravaLicenseUrl=http://localhost:8282
...
bravaServerUrl=http://ChangeMe:8282
...

That ‘ChangeMe’ is fine and will be updated during the installation!

Install Brava!

Go into the installation directory: cd ~/OpenTextBrava/

Give execution permission on the bash-script file: chmod +x installBrava.sh

Give the command: sudo ./installBrava.sh

Follow the wizard:

  • Give ‘y’ for initializing the installation wizard
  • Hit <space> till you reached the end and give ‘y’ to agree on the EULA description
  • Coffee time…☕

This is what gets installed:

  • Linux BravaPublisher in /opt/opentext/publisher/
  • BravaServer in /opt/opentext/brava/server
  • BravaSDK in /opt/opentext/brava/stagedWebApps/BravaSDK
  • BravaLicense in /opt/opentext/brava/license
License update

A Brava! license (IGCKey.lic) looks like this:

1
2
3
4
5
6
7
8
9
# Appworks / Process Suite embedded license
# For Brava! Enterprise 16.6
# Brava Server License
{license-key}
# NetItEnterprise.net License
{license-key}
# Brava Enterprise Client License
[PS_BV]
{license-key}

The embedded license file is a 30-day evaluation license. For us this is sufficient, but if you have your own license file you can update it in this location on the server: /opt/opentext/brava/license

After update restart the Tomcat service!

Starting the publisher

The ‘publisher’ is a separate service job that is installed with the Brava! installation with this file in the installation directory /BravaPublisher/publisher-1.6.0-Linux.rpm via this command during the Brava! installation rpm -ivh publisher-1.6.0-Linux.rpm, but don’t worry about it! The only thing we need to do is start it up as it won’t start by itself.

/opt/opentext/publisher/bin/publisher start

What is it? A transformation engine! What does it do? Simple, it transforms formats to a format that is viewable by the Brava! viewer. That is exactly what we need for that nasty error we get at the moment for our .docx uploaded document!

Check this supported format matrix on the Brava! viewer component.

For some more inside information: The transformation is done with several transformation drivers that convert a format to a ‘Drawing Loader’. For .docx files for example we see a call done with the Otf2dl driver and for .txt files we see calls passing by with the Txt2DL driver.

There is a ‘loaderconfig’ tool available where you can do these types of commands:

  • /opt/opentext/publisher/bin/loaderconfig -l Otf2dl
  • /opt/opentext/publisher/bin/loaderconfig -L Otf2dl
  • /opt/opentext/publisher/bin/loaderconfig -P docx

After a conversion the Drawing Loader result data is saved in the cache location: /opt/opentext/brava/dlcache/. The cache is used to show the content in AppWorks runtime.

WebApp deployment

The next step should be some web application deployment, but that was already triggered by the installer itself with an end-result in tomcat:

brava_005

You see that ‘BravaLicense’ is not started yet, but for that we just do a restart of Tomcat as the license was updated during installation.

Restart Tomcat

A simple task: systemctl restart tomcat_brava

With a view on the logfile: tail -999f /opt/tomcat_brava/latest/logs/catalina.out

Now for some validation URLs:

http://192.168.56.107:8282/BravaServer/Pop

http://192.168.56.107:8282/BravaServer/rasters?bravaserverurl=http://192.168.56.107:8282/BravaServer

http://192.168.56.107:8282/BravaServer/stamptemplates?bravaserverurl=http://192.168.56.107:8282/BravaServer

http://192.168.56.107:8282/BravaLicense/License

http://192.168.56.107:8282/BravaSDK/

http://192.168.56.107:8282/BravaSDK/ActiveX/samples/BasicFileLoad/overview.html


Update the document store connector

Time to connect Brava! to our AppWorks platform. For this we need to be in the ‘system’ organization with our ‘sysadmin’ account that has administration access.

Open the ‘System Resource Manager’ and get the properties of the ‘Repository’ service container. Enter the last tab with title ‘Document Store’ and fill-in the ‘Brava server URL’. Keep that automagically filled in ‘Brava capability set’ with value ‘PS_BV’. I saw this value also passing by in the license file, so we’ll just keep it as it!

You can also mark that ‘pre-publish’ option, but it’s not required for our purpose. In a production environment it could improve the view capabilities in runtime but can also bring more load and caching to your Brava! instance.

brava_006

Save the service container and let it restart.

If you have a separate ‘Document store’ service container for your organization available you can also do this setting in the ‘Document store’ tab of that service container of the organization!


Do a first view in Brava!

Note upfront as I also did a restart of the TomEE instance as my first preview was not picking up the Brava! Viewer in runtime!

Another note is: I replaced the default license (delivered with the platform) with an evaluation enterprise license that has the support of placing annotations on a document!

This is now the view of my document with Brava! (with enable annotation functionality)

brava_007

Just play around a bit and check out the capabilities for the end-user…Yes…They will be happy now! 😍

Oh yeah…From the developer console we also learn information from these URLs:

Hmmm…interesting bullets…for future usage!


Logging and debug levels

Before we do some deeper diving let’s find out about the logging and setting up some DEBUG levels, so we get a better view what is happening in the back-end!

This is the list of log locations I could find after installation:

1
2
3
4
5
/opt/opentext/brava/server/log/
/opt/opentext/publisher/logs/
/opt/opentext/publisher/bin/converter/loaders/OTF_Support/logs/
/opt/opentext/brava/license/log/
/opt/tomcat_brava/apache-tomcat-8.5.43/logs/

Let’s see what logfile gets an update after we’ve uploaded new content, and we view it in runtime via the Brava! viewer!

Command to search for last minute updated files: sudo find /opt -type f -cmin 1

With an interesting result where we see a lot of caching happening:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/opt/tomee/apache-tomee-plus-8.0.3/logs/catalina.out
/opt/opentext/brava/dlcache/dlcEntries
/opt/opentext/brava/dlcache/53a9c01d-feac-4558-80c5-3430cfdc544e_0800273b-f379-a1eb-8/Lorem ipsum dolor sit amet.docx
/opt/opentext/brava/dlcache/63e0785a-2f6f-45f1-98dc-fa0fcf803d96_dc_5B6B67837EA190C8A/data.txt
/opt/opentext/brava/dlcache/63e0785a-2f6f-45f1-98dc-fa0fcf803d96_dc_5B6B67837EA190C8A/cf_91CBD501D6C0C3AA4F671B9FEF35EA336D4AED87DC4081BC8679CC86ACE8E953_.txt
/opt/opentext/brava/dlcache/5a325872-28d9-4959-a977-ee6101c30585_xc_027F3B879E83C6F98/data.txt
/opt/opentext/brava/dlcache/5a325872-28d9-4959-a977-ee6101c30585_xc_027F3B879E83C6F98/Page0.zdl
/opt/opentext/brava/dlcache/5a325872-28d9-4959-a977-ee6101c30585_xc_027F3B879E83C6F98/extents-page-0.txt
/opt/opentext/brava/dlcache/5a325872-28d9-4959-a977-ee6101c30585_xc_027F3B879E83C6F98/complete.xdl
/opt/opentext/brava/dlcache/5a325872-28d9-4959-a977-ee6101c30585_xc_027F3B879E83C6F98/textinfo.txtinf
/opt/opentext/brava/dlcache/5a325872-28d9-4959-a977-ee6101c30585_xc_027F3B879E83C6F98/searchtextinfo.txtinf
/opt/opentext/brava/dlcache/ef5e4afb-3347-4a54-890a-e98478a23117_va_E5266785E77FDC375/data.txt
/opt/opentext/brava/dlcache/ef5e4afb-3347-4a54-890a-e98478a23117_va_E5266785E77FDC375/complete_page0.svgz
/opt/opentext/brava/dlcache/9f113f5e-e103-4b0d-a9a1-35627b8e6af9_ta_2E80A52040B64D306/data.txt
/opt/opentext/brava/dlcache/9f113f5e-e103-4b0d-a9a1-35627b8e6af9_ta_2E80A52040B64D306/thumbnail_page_0.jpg
/opt/opentext/brava/dlcache/5c278f47-c13c-41a3-b762-a0b58a66a130_di_24FDAC01A4D54E679/data.txt

For some more information on particular files:

‘Lorem ipsum dolor sit amet.docx’: Is my uploaded content

‘thumbnail_page_0.jpg’: Is a small thumbnail image of my uploaded content

‘searchtextinfo.txtinf’: Contains the raw text of my document…Interesting!

I would have expected some more files to be updated in the logging!

Let’s fix this with some log level updates on Brava!:

Always make sure you reset these levels back to the default value once you’re done as it will generate a lot of data with big log files!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
vi /opt/tomcat_brava/latest/webapps/BravaLicense/WEB-INF/classes/logback.xml
-----------------
<root level="debug">
<appender-ref ref="rolling" />
<appender-ref ref="stdout" />
</root>
<logger name="AuditLog" level="debug" additivity="false">
<appender-ref ref="AuditLog" />
</logger>
-----------------

vi /opt/tomcat_brava/latest/webapps/BravaServer/WEB-INF/classes/logback.xml
-----------------
<root level="debug">
<appender-ref ref="rolling" />
<appender-ref ref="stdout" />
</root>
-----------------

vi /opt/opentext/publisher/config/logback.xml
-----------------
<root level="debug">
<appender-ref ref="rolling-agent" />
</root>
<logger name="metrics" level="debug" additivity="false">
<appender-ref ref="metrics"/>
</logger>
<logger name="com.ot" level="debug" />
<logger name="com.ot.publishing.publisher.conversion" level="debug" />
-----------------

Ready? Let’s do an upload again, and you should see some more interesting information passing by in several logfiles.

These files were (for me) interesting to have a view on:

  • tail -999f /opt/opentext/publisher/logs/publisher.log
  • tail -999f /opt/opentext/publisher/logs/jobs-passed.log
  • tail -999f /opt/tomcat_brava/apache-tomcat-8.5.43/logs/catalina.out
  • tail -999f /opt/opentext/publisher/bin/converter/loaders/OTF_Support/logs/viewer.data.log
  • tail -999f /opt/opentext/publisher/bin/converter/loaders/OTF_Support/logs/dl2otf.data.log

The ‘eyes’ of the system are ready…Let’s continue…


What about annotating a document?

Now that we are able to view a document via Brava! it is time to make some annotations on a document, and the most interesting question I have is: Where are those annotations saved in the system?

Let’s find out and add an annotation first:

brava_008

If you don’t have this option available, you need to get a difference license. For this you can contact OpenText support!

You’ll get a variety of options to choose from, but we just add a simple text block:

brava_009

We just provide it with some text…

brava_010

Once done, we can save it from the menu (and later on we can also open it again from this menu, but that’s not for this post!)

brava_011

Provide the annotation save action with a nice name like ‘annotation001’ and save it:

brava_012

Ok…Now where is it saved and what format is used (I guess XML, but let’s find out)!?

A look with the CMC tool in the AppWorks is telling that it’s not saved in the document store of AppWorks…Sounds reasonable as the Brava! publisher is also not saving its data in the AppWorks storage location!

Well, let’s open the Chrome developer tools with <F12> and open the annotations again from that menu we just used. You will see these URLs passing by:

This last one is the most interesting as it gives us the information of our annotation (incl. the note itself!)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
<?xml version="1.0" encoding="UTF-8"?>
<IGCMarkupDocument xmlns="http://www.opentext.com" majorversion="2" minorversion="13">
<CDLInfo v1="5" v2="3" v3="0" v4="99">
<DriverInfo>Txt2DL</DriverInfo>
<DriverFormatVersion>1</DriverFormatVersion>
</CDLInfo>
<MeasureCategories/>
<ImageList/>
<PageList>
<Page DriverFormatVersion="1" DriverInfo="Txt2DL">
<AuthorList>
<Author name="awdev">
<Text bold="false" color="255|0|0" comment="" font="Arial" fontsize="0.2" hyperlink="" id="1" italic="false" opaque="secondarycolor" secondarycolor="255|255|128" underline="false">
<PointList pointcount="4">
<Point>
<x>1.4692555663175568</x>
<y>9.69715470599775</y>
</Point>
<Point>
<x>2.881539220163711</x>
<y>9.69715470599775</y>
</Point>
<Point>
<x>2.881539220163711</x>
<y>10.179462398305443</y>
</Point>
<Point>
<x>1.4692555663175568</x>
<y>10.179462398305443</y>
</Point>
</PointList>
<Matrix>1|0|0|1|0|-0.010862029192074019</Matrix>
<TextLine>This is my first</TextLine>
<TextLine>annotation...</TextLine>
<MetaData/>
</Text>
</Author>
</AuthorList>
</Page>
</PageList>
</IGCMarkupDocument>

Still no information where it is saved!?

Let’s dive into some code where we start with that last URL that point us to a ReST service called ‘documentservices’ location on a TomEE with port 8080! On the server it will be this location:

/opt/tomee/apache-tomee-plus-8.0.3/webapps/home#app#documentservices

After some browsing you will end in this location where you will find a class called ‘BravaOperations’ that extends the ‘DocumentStoreRestServiceBase’ class: #documentservices/WEB-INF/classes/com/opentext/docservice/rest/api/

Let’s open this class with a Java decompiler like ‘JD-GUI’ that we used on other blog posts too…

You will see that the class is starting with @Path("/bravaoperations") and that is exactly what we also see in that final URL. The next section of that URL is some kind of ID (0800273bf379a1eb821f44c099370284.1310722.327681). It should have some kind of relation with de element ID of our instanced entity together with some markup ID (I guess!?)…

We have only 1 method that does the trick:

1
2
3
4
5
6
7
8
@GET
@Path("/{markupItemId}")
@Produces({"application/xml", "application/json", "application/octet-stream"})
public Response getMarkup(@PathParam("markupItemId") String markupItemId, @Context HttpServletRequest httpServletRequest) {
...
Markup content = beanFromContext.getMarkup(markupItemId);
...
}

After some searching you eventually end up in the class ‘BravaUtil’ in this location: /opt/tomee/apache-tomee-plus-8.0.3/webapps/home#app#documentservices/WEB-INF/classes/com/opentext/docservice/rest/api/brava/

…with in that class a method public Markup getMarkup(RequestContext requestContext, String markupItemId) throws DocumentStoreException {}

With a call to: MarkupContent content = (MarkupContent)documentStoreRestClient.get("/Items(" + markupItemId + ")", MarkupContent.class, null);

Hmmm…Looks like it is saved in some kind of document store!?…I don’t see it with the CMC tool…Let’s dive into the database with HeidiSQL

There you have it:

brava_013

SELECT id, id1, s_markupfilename, s_markupcontent FROM o2appworkstipsproj_genmarkupfiles;

That is exactly the information (and XML data) I was looking for! 👊

You will also see that each annotation get its own id in the ‘id1’ column, and the ‘id’ column contains the item id of an instanced entity (the last part after the ‘.’ in the URL when you open an entity)

That’s it for the annotation part…next…


Let’s upload some video/audio content

Interesting start note: Brava! Enterprise views any video format supported by the web browser being used.

Let’s put that to a test with this video downloaded from YouTube in .mp4 format…shall we!?

That’s an error in the Brava! viewer from the publisher after the upload…

brava_014

With this line the logging: Loader not installed for extension: mp4

A correct conclusion as /opt/opentext/publisher/bin/loaderconfig -P mp4 gives me a message that the extension is not associated with a loader!

Ok…Back to this post as I don’t want to make a deeper dive on the Brava! configurations and Brava! documentation itself. Many more settings can be done on the Brava! side, but this can be a post on itself and is out of scope of this post.


I give it a well learned “DONE” where we saw some great inside on the Brava! components on our platform. The installation of Brava! is done with a usable check on how it all will be used within the AppWorks platform. We did not only see it all in runtime, but I think we also did a nice deep dive on the back-end of our server.

Other final recourses:

  • OpenText Brava! Enterprise FAQ

  • You might see the ‘IGC’ abbreviation passing by, but this will clear up some things!

  • Here the set of Brava! loaders

  • On the servers you can find the loaders in this location: /opt/opentext/publisher/config/converter/loaderprofiles/default

That’s it! Have a great week-end…Cheers!

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?