CMDBuild Forum

Workflow non funzionanti con ReadyToUser v2.3.4

Old Versions
#1

Buongiorno a tutti.

Stiamo testando CMDBuild v2.3.4 con l'addon ReadyToUse v1.0 ma i workflow non sembrano funzionare. L'applicazione all'accesso segnala l'assenza di diverse "classi" (es. AssetMgt) e quando dalla console di amministrazione si apre la pagina dei processi viene evidenziato un errore del tipo evidenziato sotto.

Immagino manchi qualcosa nella configurazione dell'integrazione con Shark, anche se abbiamo seguito le istruzioni di installazione apparentemente in modo corretto. Il resto delle funzionalità appare corretto.

L'installazione è su Ubuntu server (14.04, 64bit) con Tomcat 7.0, JDK 1.6 e Postgres 9.4

Cosa possiamo verificare per capire il problema dov'è?

Grazie!

Call: services/json/workflow/xpdlversions
------------------------------------------
Error: org.cmdbuild.workflow.CMWorkflowException: java.lang.NullPointerException
	at org.cmdbuild.workflow.service.TransactedSharkService$TransactedExecutor.initAndConnect(TransactedSharkService.java:49)
	at org.cmdbuild.workflow.service.TransactedSharkService$TransactedExecutor.execute(TransactedSharkService.java:23)
	at org.cmdbuild.workflow.service.TransactedSharkService.downloadAllPackages(TransactedSharkService.java:127)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore$LazyClassNameToPackageInfoMap.fetchProcessDefinitions(CachedProcessDefinitionStore.java:119)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore$LazyClassNameToPackageInfoMap.checkLoaded(CachedProcessDefinitionStore.java:111)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore$LazyClassNameToPackageInfoMap.getPackageInfoByClass(CachedProcessDefinitionStore.java:98)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore.getPackageId(CachedProcessDefinitionStore.java:209)
	at org.cmdbuild.workflow.xpdl.CachedProcessDefinitionStore.getPackageVersions(CachedProcessDefinitionStore.java:204)
	at org.cmdbuild.workflow.xpdl.AbstractProcessDefinitionManager.getVersions(AbstractProcessDefinitionManager.java:37)
	at org.cmdbuild.workflow.ProcessClassImpl.getDefinitionVersions(ProcessClassImpl.java:167)
	at org.cmdbuild.logic.workflow.DefaultWorkflowLogic.getProcessDefinitionVersions(DefaultWorkflowLogic.java:633)
	at org.cmdbuild.servlets.json.Workflow.xpdlVersions(Workflow.java:249)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [....]

#2

Aggiungo al post precedente che il servizio Tomcat7 gira con l'account root e che lo schema Shark nel database CMDBuild appartiene all'utente shark, così come suggerito in diversi punti e post precedenti.

 

Cosa possiamo verificare per capire dov'è il problema?

 

Grazie!

#3

AGGIORNAMENTO:

Pare che le istruzioni lette sulla modifica dell'account con cui gira Tomcat non fossero proprio corrette, pertanto è stato modificato il file sbagliato.

Il file corretto da modificare è /etc/default/tomcat7

 

cambiando le variabili TOMCAT7_USER e TOMCAT7_GROUP e impostandole a root.

Ora Shark su Tomcat parte correttamente (nessun errore in shark.log) e l'integrazione con CMDBuild funziona.

Grazie.