/ Development  

Creating a WS-AppServer service container the proper way

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips in this new year (2020!) where we continue our journey by learning, describing and having excitement about the product we work with.

In this short post we’ll cover the possibility of the creation of an WS-AppServer…A what?…A WS-AppServer…And why do we need/want such a thing?

This makes it possible to

  1. Build data models from database metadata (that is injected in the platform)
  2. Generate Java code out of these data models
  3. Generate WebServices out of these data models
  4. Generate WebServices out of Java sources…And this where our fun starts in the next post!
  5. Can run SQL queries on data models

And what is a data model? It’s an abstraction model that standardizes the organization of elements with data, relations and properties like in the ‘real-world’…sounds familiar?…This matches the entity modeling we described in other posts on this site!

So, a great feature to have in our platform, but not by default available when you installed AppWorks from scratch. It’s also one of those things you always want to have next to your SVN, Mail and OTDS.

Let get right into it…

Spin up the machine and login to our organization with the ‘sysadmin’ user and open the ‘System Resource Manager’.

The documentation tells us to do these steps in the ‘System’ part of our platform, but we’ll see that this will cause a problem later. I don’t know why, but on the moment of service generation in my organization I was not able to select a ‘Service Group’ where the WS-AppServer could be found.

We will do almost the same steps as we created that new ‘DocumentumStore’ of type ‘Document store’. So, just click the ‘New service group’ icon and follow along with the below steps.

wsapp_001

Select the ‘WS-AppServer’ connector and click ‘Next >’

wsapp_002

Give the name ‘WS-AppServer’ and click ‘Next >’

wsapp_003

Assign to OS Process ‘Application Server’ which is our TomEE instance where the AppWorks platform is running. Also enable the ‘Automatic’ startup. Then click ‘Next >’

In the JRE Configuration you can modify the class path. Here you can define for example your custom classes/jar files that should be found be this service.

Point to the absolute location and make sure the ‘tomcat’ user that is running the TomEE instance has permission on the folder/files. So, it would be good to create a ‘custom’ folder in the AppWorks instance directory where ‘tomcat’ is the owner with sudo chown tomcat:tomcat custom.

This is an example on my CentOS machine (On Linux you separate them with ‘:’ where Windows uses an ‘;’)

/opt/opentext/AppWorksPlatform/defaultInst/custom/your_file.jar:/opt/opentext/AppWorksPlatform/defaultInst/custom/your_second.jar

Also note that the service gets connected to the ‘Application Server’ on OS level. When you restart TomEE with systemctl restart tomee you also need to spin-up this service container again (as this is not always detected correctly from what I’ve seen!

wsapp_004

You can unmark the ‘Configure Database’ as we don’t need it for now.

When you create you WS-AppServer in the ‘System’ organization you can select the PostgreSQL database connector from our AppWorks installation. But you can also create a new database connection from where you want to extract all kind of (custom) database metadata.

wsapp_005

Click ‘Finish’ and see the result…

wsapp_006

When you now get the properties of the ‘WS-AppServer’ and browse to the ‘Log Settings’ tab you can see that this service is logging out to:

tail -f /opt/opentext/AppWorksPlatform/defaultInst/Logs/appworks_tips#ws-appserver#ws-appserver.xml

That is a simple ‘DONE’ this time, but very valuable to understand the features of this great service. We will start to use this service container in the next post. Have a great day and see you the next time on a new installment of AppWorks Tips.

Don’t forget to subscribe to get updates on the activities happening on this site.