How to use Asynchronous logging

How to use Asynchronous logging

  

Ana Santos wrote the following in this post. Since that is not directly related to the thread, I have forked it to this thread.


"We need to log information for requests and responses either through outsystems modules or through .NET extensions.

Currently, we're using GenericExtendedActions.Audit to do this, but Service Center cannot give us all the information about this logs (I assume that is because of the size limit you referred).

What I actually need to know is how can we implement asynchronous logging in this situtation. Can you help me?

Thank you,

Ana Santos"


In attachment you can find a sample application making use of the Log Record action of Asynchronous Logging built-in extension. In order to overcome the "could not convert to record" error all I had to do was change the type of the Log variable to be of type Record of Log instead of Log.


I hope this helps.

I'm just replying so this doesn't show up in the "unanswered" list anymore :).

Does this work in a multi-tenant environment? I'm getting a zero tenant_id for records inserted using LogRecord even though the module is multi-tenant!

Khalil, have you exposed the tenant_id and filled it with the correct value? LogRecord is rather low-level, I don't think it has knowledge of multi-tenancy.

Hi there Ricardo!

I'm using the latest version of the platform and using the action AsynchronousLogging > LogRecord.

I've done the correct cast ToObject of my entity record, but still, I'm getting the following error on ServiceCenter:

 - Unable to convert to record


Any idea of what can be the cause?

Thanks in advance.


Best regards,

Ricardo Saraiva wrote:

Hi there Ricardo!

I'm using the latest version of the platform and using the action AsynchronousLogging > LogRecord.

I've done the correct cast ToObject of my entity record, but still, I'm getting the following error on ServiceCenter:

 - Unable to convert to record


Any idea of what can be the cause?

Thanks in advance.


Best regards,

I had the following problem so it might help you:

If you have an entity called ENTITY1, and a variable VARIABLE1 of type (entity1 record), then you cannot use ToObject(variable1). You need to use ToObject(variable1.entity1).

I just solved this by trial and error so I don't know the explanation.

If you have a Record containing multiple Entities, the LogRecord doesn't know which Entity to log. In that case, you need to explicitly indicate which Entity by using the variable.entity syntax. I'm not sure whether LogRecord is smart enough to do so when there's only one entity in the Record.

Solution

Hey guys,

thanks for your feedback.

Anyway, I solved the issue and understood why it happens.
I was using a variable of type entity, instead of type record. It seems that LogRecord is not "smart" enough like entity actions for Create, CreateOrUpdate or Update - those actions can receive an entity variable or a record of that entity type and create the record in the database anyway. However, LogRecord only accept record's as input.

So in practice:

I have an ENTITY1 and I created a VARIABLE1 of type Record: ENTITY1...

...and problem solved! :)


Best regards,
--
Ricardo Saraiva

Solution

Hi Ricardo,

Yes, that's a common problem with many "older" (pre-9) extensions, they rely on Entity data and structures to be encapsulated in a Record. Apparently, it ain't called LogRecord for nothing :). Glad you solved it.

Now I realized that LogRecord is asynchronous but executes under the same transaction, or am I missing something?

If is true, this won't work for my logging purposes, since when logging an error raised by an exception (for example), I wish to rollback the operations but commit the log.

Hi André,

LogRecord is fully asynchronous. If there's an error, you'll find it in the error logging in Service Center.

Hi Kilian. Yes, you're correct. I've missed that it takes some time to register the record in database, since LogRecord uses the message queue... this can be a problem for me if this time takes too long.