Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

Health and monitoring; including sharing the details and collaborating about it! I see it going wrong in so many projects. The reason (at least for me) is unclear as it’s one of the main “eyes” of your platform. When things go wrong it’s your first sign to act…proactively! Don’t wait until end-users start to complain, but monitor what happens in the system. This is not the first post we’ll talk about monitoring; probably also not the last one, but I found (again!) some interesting things to share about the topic…read and enjoy!

Let’s get right into it…

When we talk about health and monitoring, there are two main URLs important:

1. OPA overall health at: http://opa.mydomain.com/cordysguest/com.eibus.web.tools.healthCheck.HealthCheckURL.wcp

2. OPA services health at: http://opa.mydomain.com/home/system/app/mp/health/ready

Notes:

• See also the “HealthCheckURL” section in the administration guide of the OPA platform.
• An organization specific URL has the same outcome: http://opa.mydomain.com/home/opa_tips/app/mp/health/ready

This is the default JSON output on {org_name}/system/app/mp/health/ready. See screenshot from above:

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

{
  "checks": [
    {
      "name": "Initialization",
      "status": "UP"
    },
    {
      "name": "service.system.monitor",
      "status": "UP"
    },
    {
      "name": "service.system.LDAP",
      "status": "UP"
    },
    {
      "name": "service.system.Platform",
      "status": "UP"
    },
    {
      "name": "service.system.XForms",
      "status": "UP"
    },
    {
      "name": "service.system.Notification",
      "status": "UP"
    },
    {
      "name": "service.system.CAP",
      "status": "UP"
    }
  ],
  "status": "UP"
}

This JSON result gives me two valid questions:

1. These are service container states, but where is the rest; Like the BPM, CWS, or Logging containers?
2. What if I create my own service container? Will it magically be in the result?

Time for a Q/A

#RTFM tells me about four important properties in the wcp.properties configuration file for the OPA platform relevant for our answers:

1
2
3
4

platform.management.health.ready.availability=true|false
platform.management.health.ready.components=...
platform.organizations.{org_name}.management.health.ready.availability=true|false
platform.organizations.{org_name}.management.health.ready.components=...

This is the documentation for those true|false properties:

• When set to TRUE, it returns the readiness of the components provided in the components property.
• When set to FALSE, it excludes the components provided.

!?!?…Is it me? Or is this just OpenText documentation you require to read up-side-down; You tell me! Also, the true|false does not always match as expected…See below!
…
FYI: Use service. and NOT Service. with a capital (as in the up-side-down docs!) #SABOTAGE…Or that’s because I’m on Unix!?

…

Before we start; I have an organization opa_tips and have three extra service container up and running serving requests for my current project (all with a corresponding service group): sc_appserver, sc_email, and sc_http.

It’s about time to assess some settings; IMPORTANT: After each change in the wcp.properties file, you need to restart TomEE!

You can edit the file via: sudo vi /opt/opentext/ProcessAutomationCE/defaultInst/config/wcp.properties

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
42

##########
# Option 1 (see it all)
##########
# Will show ALL service containers...exactly what you want!
# I taught going nuts, but that's NOT a typo for false|true
platform.management.health.ready.availability=false
platform.organizations.opa_tips.management.health.ready.availability=true

##########
# Option 2 (see the default)
##########
# Will show only the default service containers from /system again...Yes, I assessed it on my 26.1 VM!
platform.management.health.ready.availability=true
platform.organizations.opa_tips.management.health.ready.availability=false

##########
# Option 3 (see nothing)
##########
# Will show NO service containers...assessed on my 26.1 VM!
platform.management.health.ready.availability=true
platform.management.health.ready.components=empty
platform.organizations.opa_tips.management.health.ready.availability=false

##########
# Option 4 (see what you want; both TRUE!)
##########
# Will show only the service containers included by the components list for the shared organization 'system'
platform.management.health.ready.availability=true
platform.management.health.ready.components=service.LDAP,service.Repository,service.Collaborative Workspace
# Will show only the service containers included by the components list for my own organization 'opa_tips'
platform.organizations.opa_tips.management.health.ready.availability=true
platform.organizations.opa_tips.management.health.ready.components=service.sc_appserver,service.sc_email,service.sc_http

##########
# Option 5 (see what you don't want; both FALSE!)
##########
# Will only ALL show service containers excluded by the components list for the shared organization 'system'
platform.management.health.ready.availability=false
platform.management.health.ready.components=service.system.Collaborative Workspace
# Will only ALL show service containers excluded by the components list for my own organization 'opa_tips'
platform.organizations.opa_tips.management.health.ready.availability=false
platform.organizations.opa_tips.management.health.ready.components=service.opa_tips.sc_appserver

From an administration point of view, I would always go for option 1…showing full health, but it’s all up to you now!

…

I was also curious where these health services live insight the platform!? I found this location:

/opt/tomee/apache-tomee-plus-10.1.2/webapps/home#app#mp

In this directory, these two class files are interesting to further do your investigations:

1
2

com.opentext.health.AppworkHealthEndPoint
com.opentext.health.HealthChecksEndpoint

That’s a great “DONE” where we expose wrongly documented topics about a high value feature; it almost feels as if they (OpenText) do it wrongly on purpose, but I’ll give them the benefit of the doubt. However, we now have splendid examples available on how it all works properly. It’s now up to you to expand this knowledge to your maintenance team and make sure to properly monitor these end-point for failure. Have a great weekend and I will see you next week on another topic about “Process Automation Tips”.

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 Process Automation guy”?