cancel
Showing results for 
Search instead for 
Did you mean: 

Logging which user executed a simple workflow

dnallsopp
Champ in-the-making
Champ in-the-making
I would like to use a simple workflow to implement an Accept/Reject document review, and move the document into an Accept folder or a Reject folder depending on the decision. All easy so far…

However, I need to be able to log this decision, and the identity of the user who made it, to an audit log on a remote server.

Ideally I would like to hook something into the simple workflow that will call a specific log4j logger that is picked up by syslog, using the log4j SysLogAppender.

Is there any way to do this?

Update: if the destination folders (Accept/Reject) had a rule that triggered an action when the file arrived, would that action be run in the context of the same user that ran the workflow? If so, this would probably be a solution, if Actions can access the 'current user'…?

Alternatively would it be possible to use Alfresco Audit functionality, and run an Action to query the Audit system and send it to the external log?
5 REPLIES 5

afaust
Legendary Innovator
Legendary Innovator
Hello,

yes, yes and yes are the answers to your questions.

Yes - all code run synchronously as a result of a user interaction are run in the context of the user performing the interaction (AuthenticationUtil.getFullyAuthenticatedUser is your go-to-utility here).

Yes - actions can access the current user. Even asynchronous actions can access the current user based on the user whose interaction caused the action to be queued in the first place.

Yes - you can use the audit functionality to log the decision as all decisions are performed via the auditable service operation endTask on the workflow service. You would need to extract / generate some additional data for the audit entry though, as the basic set for that operation only contains the task id and transition. But based on the available data, you can build up a complete snapshot of the decision and save it as an audit entry.

Regards
Axel

janguela
Champ in-the-making
Champ in-the-making
Hello Axel, I have questions regarding your answer.
Yes - you can use the audit functionality to log the decision as all decisions are performed via the auditable service operation endTask on the workflow service. You would need to extract / generate some additional data for the audit entry though, as the basic set for that operation only contains the task id and transition. But based on the available data, you can build up a complete snapshot of the decision and save it as an audit entry.

Is this still valid for Activiti in 4.0.x?

If yes, could you please provide an example?

I have tried to configure the audit module to track the endTask events as you mentioned in your post with :

<?xml version='1.0' encoding='UTF-8'?>
<Audit xmlns="http://www.alfresco.org/repo/audit/model/3.2"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.alfresco.org/repo/audit/model/3.2 alfresco-audit-3.2.xsd">

   <DataExtractors>
      <DataExtractor name="simpleValue"
         class="org.alfresco.repo.audit.extractor.SimpleValueDataExtractor" />
   </DataExtractors>

   <DataGenerators>
      <DataGenerator name="transactionId"
         class="org.alfresco.repo.audit.generator.TransactionIdDataGenerator" />
   </DataGenerators>

   <PathMappings>
      <PathMap source="/myApp" target="/myApp" />
      <PathMap source="/repository" target="/myApp" />
      <PathMap source="/alfresco-api" target="/myApp" />
   </PathMappings>

   <Application name="myApp" key="myApp">
      <AuditPath key="pre">
         <AuditPath key="WorkflowService">
            <AuditPath key="endTask">
               <AuditPath key="args">
                  <AuditPath key="taskId">
                     <RecordValue key="taskId" dataExtractor="simpleValue" />
                  </AuditPath>
                  <AuditPath key="transitionId">
                     <RecordValue key="transitionName" dataExtractor="simpleValue" />
                  </AuditPath>
               </AuditPath>
            </AuditPath>
         </AuditPath>
      </AuditPath>
   </Application>
</Audit>


But it seems to catch ONLY the endTask of the StartTask. No more logs for the others tasks in the process.


2012-07-02 17:20:47,927  DEBUG [repo.audit.inbound] [http-8080-5]
Inbound audit values:
    /alfresco-api/pre/WorkflowService/endTask/args/taskId=activiti$start20422
    /alfresco-api/pre/WorkflowService/endTask/args/transitionId=null
2012-07-02 17:20:47,952  DEBUG [repo.audit.inbound] [http-8080-5]
Inbound audit values:
    /alfresco-api/post/WorkflowService/endTask/no-error=null
    /alfresco-api/post/WorkflowService/endTask/args/taskId=activiti$start20422
    /alfresco-api/post/WorkflowService/endTask/args/transitionId=null

Regards,
Jordi

afaust
Legendary Innovator
Legendary Innovator
Hello,

yes, this is still valid for Activiti in 4.x since the Alfresco service abstracting from the concrete workflow implementation is the one being audited and not the actual workflow component running internally. The configuration you provided already shows how to configure an audit application for this.

Looking at the source code of Alfresco 4.0.1 I recognize the stated behavior to be the consequence of a configuration bug in standard Alfresco. In the form-services-context.xml, the taskFormProcessor bean is injected with a reference to the WorkflowService implementation bean instead of the public service bean (as is done with the workflowFormProcessor, same file just a few lines above). This is why the start is being audit-logged, but further transitions aren't. Only public service beans are audit-enabled.

In the short term, you should correct that locally for your tests. But please also log a support ticket with Alfresco (if you are a paying customer) or let me / us know, so at least a JIRA ticket can be opened.

Regards
Axel

janguela
Champ in-the-making
Champ in-the-making
Hello,
Looking at the source code of Alfresco 4.0.1 I recognize the stated behavior to be the consequence of a configuration bug in standard Alfresco. In the form-services-context.xml, the taskFormProcessor bean is injected with a reference to the WorkflowService implementation bean instead of the public service bean (as is done with the workflowFormProcessor, same file just a few lines above). This is why the start is being audit-logged, but further transitions aren't. Only public service beans are audit-enabled.

Axel, you are gold! That solved the issue.

But please also log a support ticket with Alfresco (if you are a paying customer) or let me / us know, so at least a JIRA ticket can be opened.

I have created a ticket with Alfresco. I will post the JIRA when created.

janguela
Champ in-the-making
Champ in-the-making