Good morning Mika,
In truth, I haven't done this yet for 7 (it's on my list though!) -- but in 6.2 it was done through a spring configuration file, kinda like this --
-- you don't have to have a multiple processors of course, I'm just showing you an example of something that I have used in the past. With that defined, again in 6.2, there was an additional change that you had to the web.xml to make sure that the spring config files were loaded
.. then you just use the LR API by creating and AuditMessage entity, setting the data, and then using the AuditRouterUtil to ship it off. In your implementation class (for the Database of course) you would use your service builder api to store the records.
Now the question that remains is, how do we do all of this is Liferay 7? Well, I think, and this is just speculation without trying it (I'm just looking at the existing Liferay source for hints), you provide the same xyz-audit.xml file, but you place it in your xyz-service module under /resources/META-INF/spring -- like this https://github.com/liferay/liferay-portal/tree/master/modules/apps/twitter/twitter-service/src/main/resources/META-INF/spring -- and I suspect that during deployment it will get picked up.
Again though, that is an untested theory -- why don't you give it a shot and let me know?
In truth, I haven't done this yet for 7 (it's on my list though!) -- but in 6.2 it was done through a spring configuration file, kinda like this --
<beans default-destroy-method="destroy" default-init-method="afterPropertiesSet" xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<!-- Router -->
<bean id="com.liferay.portal.kernel.audit.AuditRouter" class="com.xyz.audit.router.YourCustomAuditRouter">
<property name="globalAuditMessageProcessors">
<list value-type="com.liferay.portal.kernel.audit.AuditMessageProcessor">
<ref bean="com.xyz..audit.processor.DatabaseAuditRouterProcessor" />
<ref bean="com.xyz..audit.processor.ElasticsearchAuditRouterProcessor" />
<ref bean="com.xyz..audit.processor.FileAuditRouterProcessor" />
</list>
</property>
</bean><!-- Processors -->
<bean id="com.xyz.audit.processor.DatabaseAuditRouterProcessor" class="com.xyz.audit.processor.DatabaseAuditRouterProcessor" />
<bean id="com.xyz.audit.processor.ElastisearchAuditRouterProcessor" class="com.xyz.audit.processor.ElasticsearchAuditRouterProcessor" />
<bean id="com.xyz.audit.processor.FfileAuditRouterProcessor" class="com.xyz.audit.processor.FileAuditRouterProcessor" />
</beans>-- you don't have to have a multiple processors of course, I'm just showing you an example of something that I have used in the past. With that defined, again in 6.2, there was an additional change that you had to the web.xml to make sure that the spring config files were loaded
<!--?xml version="1.0"?-->
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<context-param>
<param-name>portalContextConfigLocation</param-name>
<param-value>/WEB-INF/classes/META-INF/xyz-audit-spring.xml</param-value>
</context-param>
</web-app>
.. then you just use the LR API by creating and AuditMessage entity, setting the data, and then using the AuditRouterUtil to ship it off. In your implementation class (for the Database of course) you would use your service builder api to store the records.
Now the question that remains is, how do we do all of this is Liferay 7? Well, I think, and this is just speculation without trying it (I'm just looking at the existing Liferay source for hints), you provide the same xyz-audit.xml file, but you place it in your xyz-service module under /resources/META-INF/spring -- like this https://github.com/liferay/liferay-portal/tree/master/modules/apps/twitter/twitter-service/src/main/resources/META-INF/spring -- and I suspect that during deployment it will get picked up.
Again though, that is an untested theory -- why don't you give it a shot and let me know?
The fully flushed out solution is a EE/DXP thing, but all the plumbing you need to make it work should be there in the CE version as well. It's been a while since I had to tackle this for 6.2 CE or 7.0 CE but if my memory serves me correctly there are two missing pieces.
1. There is no "message processor" registered at the liferay/audit message bus endpoint to do something with the message when it gets there, so it's basically just dropped. If you implement the processors then your records should be recorded. As David has said though, the way you implement them of course is different from 6.2 to 7. I think I posted above some details about how to do it in 6.2, in 7, it should be just a case of registering the correct OSGI services.
2. The second piece I think that is missing would be the control panel portlets that are used to render the records that are currently stored in the database. I suppose this is an optional steps because you can get those records however you like, and you don't even necessarily store them in the Liferay database anyway (depending on your volume you probably want to store them elsewhere really). If you do want to add this in though, it's just a control panel portlet (in 6.2) or a Panel App in 7.x -- which basically amounts to a Liferay MVC portlet that uses the *LocalService classes to read the records and then something like a search container (or however you want to handle pagination) for sifting through the records.
... or, you could just license DXP and then have it all in place and fully supported.
1. There is no "message processor" registered at the liferay/audit message bus endpoint to do something with the message when it gets there, so it's basically just dropped. If you implement the processors then your records should be recorded. As David has said though, the way you implement them of course is different from 6.2 to 7. I think I posted above some details about how to do it in 6.2, in 7, it should be just a case of registering the correct OSGI services.
2. The second piece I think that is missing would be the control panel portlets that are used to render the records that are currently stored in the database. I suppose this is an optional steps because you can get those records however you like, and you don't even necessarily store them in the Liferay database anyway (depending on your volume you probably want to store them elsewhere really). If you do want to add this in though, it's just a control panel portlet (in 6.2) or a Panel App in 7.x -- which basically amounts to a Liferay MVC portlet that uses the *LocalService classes to read the records and then something like a search container (or however you want to handle pagination) for sifting through the records.
... or, you could just license DXP and then have it all in place and fully supported.