September 30, 2017

How to setup openMAINT workorders on Win Server VPS with Shark Together Workflow Server

By  OpenMAINT & Asset Tiger, OpenMAINT Setup  0 Comments

This has been a challenge. It has taken me a couple of weeks to crack, tinkering with it on and off.

If you follow the setup for the localhost Link  you are almost there. I did this setup on my Amazon AWS EC2 and Contabo servers, but both of them errored out (see errors at bottom of page).

I found that the shark.war file bundled with the openMAINT download was corrupted and so downloaded another.

In the later downloaded for the shark file at https://sourceforge.net/projects/cmdbuild/files/2.4.3/shark-cmdbuild-2.4.3.zip/download the shark-cmdbuild-2.4.3.zip file contains a readme file that states:

Configure shark/conf/Shark.conf changing the section at the end of the file
named “CMDBuild Custom Components Settings”:

* “org.cmdbuild.ws.url” should be the root URL of CMDBuild
* “org.cmdbuild.ws.username” and “org.cmdbuild.ws.password” should refer to
an existing user in the “serviceusers.privileged” of CMDBuild’s auth.conf

In shark/META-INF/context.xml change the name of the database, using the name
of the CMDBuild database (ex. url=”jdbc:postgresql://localhost/${cmdbuild}”
should be changed to url=”jdbc:postgresql://localhost/cmdbuild” for a
database named “cmdbuild” in a local PostgreSQL installation).

Please note that Shark uses the same db of CMDBuild, storing its data inside
the “shark” schema. If you want to restore an empty schema you can run
${cmdbuild_home}/WEB-INF/sql/shark_schema/02_shark_emptydb.sql

The user of shark in postgres is created by CMDBuild with the following sql
(${cmdbuild_home}/WEB-INF/sql/shark_schema/01_shark_user.sql)

CREATE ROLE shark LOGIN
ENCRYPTED PASSWORD ‘md5088dfc423ab6e29229aeed8eea5ad290’
 NOSUPERUSER NOINHERIT NOCREATEDB NOCREATEROLE;
ALTER ROLE shark SET search_path=pg_default,shark;

Please note that the last line is absolutely needed when using Shark on
CMDBuild’s database.

 

When Shark is up and running, configure the workflow module in the
Administration area.

Which I did on my VPS systems.

Then I broke one of my localhost versions that had workorders running and started looking at the permissions on PostgreSQL for the Shark Login.

For the one that I followed:

You will see that there are no permissions

Whereas the initial one that I had on my local host had:

 

Superuser permissions. As soon as this was changed the workorders work fine. Cogs are the icons next to the process items of  Maintenance requests & workorders.

So the Readme.txt file basically misleads you to give the opposite of the permissions that you require, but suggests that only the last line is necessary.

Anyway, Happy Days, I now have the Server up and running and I can now:

1/ Do Space, Asset & Inventory

2/ Do Maintenance Requests & Workorders.

NOTE: There are a couple of misleading things in the video on corrective maintenance process to how it needs to be done.

Check the blog out for workorders to see what the process is.

3/ Can explore  financial Management module and see what is in store for that.

More on this after I’ve played with it and broken it a few times.

I hope this helps a few of you along.

I had looked on the CMDBuild.org/ forum and found others with similar issues but only the usual misleading cryptic replies from Tecnoteca on the subject, if they bothered to respond at all. ( I do wonder if they delete some of the forum question/answers as there seems to be a dearth of information on there.

The way to alter the shark login role is as follows:

When you look at login roles – shark, it will not look as if its changed. Refresh the item and you can see that it has updated

ALTER ROLE shark LOGIN
ENCRYPTED PASSWORD ‘md5088dfc423ab6e29229aeed8eea5ad290’
SUPERUSER INHERIT CREATEDB CREATEROLE;
ALTER ROLE shark SET search_path=pg_default,shark;

 

Background Errors on Server Shark setup

The errors were pretty much as follows when looking at the C:/tomcat/log/shark.txt file, the below is a portion of the log file:

First there is SharkUtilities -> synchronizing XPDL cache

Then following that the last few lines repeat ERROR: permission denied for relation shkresourcestable

  • 2017-09-29 22:08:55,657: SharkEngineManager -> Working with ‘org.enhydra.shark.CallbackUtil’ implementation of core CallbackUtilities API
  • 2017-09-29 22:08:55,657: SharkEngineManager -> Working with ‘org.enhydra.shark.SharkObjectFactoryExt’ implementation of core SharkObjectFactory API
  • 2017-09-29 22:08:55,657: SharkEngineManager -> Working with ‘org.enhydra.shark.StandardToolActivityHandler’ implementation of core ToolAgentManager API
  • 2017-09-29 22:08:55,657: SharkEngineManager -> Working with ‘org.enhydra.shark.logging.StandardLoggingManager’ implementation of Logging API
  • 2017-09-29 22:08:56,212: StandardAssignmentManager -> Working with ‘org.enhydra.shark.usergroup.DODSUserGroupManagerAdmin’ implementation of UserGroup API
  • 2017-09-29 22:08:56,297: StandardAssignmentManager -> Working with ‘org.enhydra.shark.partmappersistence.DODSParticipantMappingAdmin’ implementation of ParticipantMapping API
  • 2017-09-29 22:08:56,297: SharkEngineManager -> Working with ‘org.enhydra.shark.assignment.StandardAssignmentManager’ implementation of Assignment API
  • 2017-09-29 22:08:56,297: Process Cache configured – max. size is 100
  • 2017-09-29 22:08:56,297: Resource Cache configured – max. size is 100
  • 2017-09-29 22:08:56,297: SharkEngineManager -> Working with ‘org.enhydra.shark.caching.LRUCacheMgr’ implementation of Caching API
  • 2017-09-29 22:08:56,428: DODSPersistentManager -> persisting String variables into BLOB for sizes greater than 4000
  • 2017-09-29 22:08:56,428: SharkEngineManager -> Working with ‘org.enhydra.shark.instancepersistence.DODSSelectivePersistenceManager’ implementation of InstancePersistence API
  • 2017-09-29 22:08:56,428: DODSGlobalPersistenceManager -> persisting String data into BLOB for sizes greater than 4000
  • 2017-09-29 22:08:56,428: SharkEngineManager -> Working with ‘org.enhydra.shark.globalpersistence.DODSGlobalPersistenceManager’ implementation of GlobalPersistence API
  • 2017-09-29 22:08:57,283: SharkEngineManager -> Working with ‘org.cmdbuild.workflow.CMDBuildEventAuditManager’ implementation of EventAudit API
  • 2017-09-29 22:08:57,315: SharkEngineManager -> Working with ‘org.enhydra.shark.repositorypersistence.DODSRepositoryPersistenceManager’ implementation of RepositoryPersistence API
  • 2017-09-29 22:08:57,315: SharkEngineManager -> Working with ‘org.enhydra.shark.scripting.StandardScriptingManager’ implementation of Scripting API
  • 2017-09-29 22:08:57,315: SharkEngineManager -> Working without Security API implementation – SecurityManager is not specified.
  • 2017-09-29 22:08:57,384: StandardToolAgentManager -> Working with ‘org.enhydra.shark.appmappersistence.DODSApplicationMappingAdmin’ implementation of ApplicationMapPersistence API
  • 2017-09-29 22:08:57,384: SharkEngineManager -> Working with ‘org.enhydra.shark.toolagent.StandardToolAgentManager’ implementation of ToolAgentManager API
  • 2017-09-29 22:08:57,384: SharkEngineManager -> Working without wfEngineInteroperability API implementation – WfEngineInteroperability implementation is not specified.
  • 2017-09-29 22:08:57,399: SharkUtilities -> synchronizing XPDL cache
  • 2017-09-30 11:06:06,921:  <SqlQueryExecute><SqlQueryException>(<Replicated>:ERROR: permission denied for relation shkresourcestable)
  • 2017-09-30 11:06:06,995:  <SqlQueryExecute><SqlQueryException>(<Replicated>:ERROR: permission denied for relation shkresourcestable)
  • 2017-09-30 11:06:07,025:  <SqlQueryExecute><SqlQueryException>(<Replicated>:ERROR: permission denied for relation shkresourcestable)
  • 2017-09-30 11:06:07,051:  <SqlQueryExecute><SqlQueryException>(<Replicated>:ERROR: permission denied for relation shkresourcestable)
  • 2017-09-30 11:06:07,081:  <SqlQueryExecute><SqlQueryException>(<Replicated>:ERROR: permission denied for relation shkresourcestable)
  • 2017-09-30 11:06:07,121:  <SqlQueryExecute><SqlQueryException>(<Replicated>:ERROR: permission denied for relation shkresourcestable)

Whereas the localhost C:/tomcat/log/shark.txt shows SharkUtilities -> synchronizing XPDL cache and then finishes

  • 2017-09-30 19:03:23,592: SharkEngineManager -> Working with ‘org.enhydra.shark.CallbackUtil’ implementation of core CallbackUtilities API
    2017-09-30 19:03:23,592: SharkEngineManager -> Working with ‘org.enhydra.shark.SharkObjectFactoryExt’ implementation of core SharkObjectFactory API
    2017-09-30 19:03:23,592: SharkEngineManager -> Working with ‘org.enhydra.shark.StandardToolActivityHandler’ implementation of core ToolAgentManager API
    2017-09-30 19:03:23,592: SharkEngineManager -> Working with ‘org.enhydra.shark.logging.StandardLoggingManager’ implementation of Logging API
    2017-09-30 19:03:24,061: StandardAssignmentManager -> Working with ‘org.enhydra.shark.usergroup.DODSUserGroupManagerAdmin’ implementation of UserGroup API
    2017-09-30 19:03:24,139: StandardAssignmentManager -> Working with ‘org.enhydra.shark.partmappersistence.DODSParticipantMappingAdmin’ implementation of ParticipantMapping API
    2017-09-30 19:03:24,139: SharkEngineManager -> Working with ‘org.enhydra.shark.assignment.StandardAssignmentManager’ implementation of Assignment API
    2017-09-30 19:03:24,139: Process Cache configured – max. size is 100
    2017-09-30 19:03:24,139: Resource Cache configured – max. size is 100
    2017-09-30 19:03:24,139: SharkEngineManager -> Working with ‘org.enhydra.shark.caching.LRUCacheMgr’ implementation of Caching API
    2017-09-30 19:03:24,827: DODSPersistentManager -> persisting String variables into BLOB for sizes greater than 4000
    2017-09-30 19:03:24,827: SharkEngineManager -> Working with ‘org.enhydra.shark.instancepersistence.DODSSelectivePersistenceManager’ implementation of InstancePersistence API
    2017-09-30 19:03:24,827: DODSGlobalPersistenceManager -> persisting String data into BLOB for sizes greater than 4000
    2017-09-30 19:03:24,827: SharkEngineManager -> Working with ‘org.enhydra.shark.globalpersistence.DODSGlobalPersistenceManager’ implementation of GlobalPersistence API
    2017-09-30 19:03:26,186: SharkEngineManager -> Working with ‘org.cmdbuild.workflow.CMDBuildEventAuditManager’ implementation of EventAudit API
    2017-09-30 19:03:26,233: SharkEngineManager -> Working with ‘org.enhydra.shark.repositorypersistence.DODSRepositoryPersistenceManager’ implementation of RepositoryPersistence API
    2017-09-30 19:03:26,233: SharkEngineManager -> Working with ‘org.enhydra.shark.scripting.StandardScriptingManager’ implementation of Scripting API
    2017-09-30 19:03:26,233: SharkEngineManager -> Working without Security API implementation – SecurityManager is not specified.
    2017-09-30 19:03:26,358: StandardToolAgentManager -> Working with ‘org.enhydra.shark.appmappersistence.DODSApplicationMappingAdmin’ implementation of ApplicationMapPersistence API
    2017-09-30 19:03:26,358: SharkEngineManager -> Working with ‘org.enhydra.shark.toolagent.StandardToolAgentManager’ implementation of ToolAgentManager API
    2017-09-30 19:03:26,358: SharkEngineManager -> Working without wfEngineInteroperability API implementation – WfEngineInteroperability implementation is not specified.
    2017-09-30 19:03:26,389: SharkUtilities -> synchronizing XPDL cache

So it looks as if there are problems writing to the shark tables. But, as per the CMDBuild Technical Manual (P16) we have changed ownership of this, but still there are permission issues.

( I noted that the Schema was changed to owned by Shark rather than postgres, but the tables in the shark schema are all still owned by postgres, and changing individual table ownership made no difference at all, it still didn’t work)

Post Views: 262

Related Posts

Add a Comment