How to catch CRUD operations performed by built in REST-API

Hi,

We have a customer that are building a solution ontop of the SuperOffice built in REST-api.

Is it possible somehow to "catch" when changes (CRUD operations) are happening to copmaines/contactapersons via the built in REST-API in SuperOffice?

If yes? How could it be done? 

We would like to catch this to be able to take action and for instance log this, or send notifiaction to other systems etc.

best regards

/Anders

RE: How to catch CRUD operations performed by built in REST-API

HI Anders,

Onsite installations can use:

  1. NetServer Service Events
  2. WebHooks

Online installations can use:

  1. WebHooks
  2. Zapier

Hope this helps!

Av: Tony Yates 25. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

Thanks Tony!

That will help us taking the discussion further internally and also on the discussion with the customer.

Didn't tell but it is an on prem customer and based on that what would be the:

1. The most powerfull solution to use?

2. The most simple to implement but still catching when companies / persons are created changed

 

I guess this also anwsers some of my questions around logging in this thred:
https://community.superoffice.com/en/technical/Forum/rooms/topic/superoffice-product-group/crm-web-application/what-logging-are-possible-today-in-the-product/

I guess it would be possible to build a logging solution by using either of the above methods?
Are SuperOffice RND planning any bigger chnages around how and what could be logged?
I could bet that other customers also would like to have better oportunites to log things that happens in the application so I would like you to consider bulding a generic solution that would benfit all superoffice customers.

If you have time please comment in my thread about logging.

Best regards
/Anders

Av: Anders Larsson 25. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

Just a thought about BulkUpdates.

I read in another post (don't remember the link) that BulkUpdates didn't generate Update Events when executed. I think the context was monitoring using WebHooks. Is this correct (I might have remember it wrong) and if so, is that still the case in current versions?

I suppose that NetServer Service Events are the solution that gives the best granularity when it comes to which events that are possible to monitor. As I understand it, using that kind of method you get access to all events available in NetServer, while WebHooks and triggers represent a wrapped subset of selected events to be able to monitor.

If that is true, will the NetServer Service Events-method give a possibility to monitor a lower level event that still makes it possible to monitor BulkUpdate-changes (if the above statement is true)?

Which level of transactional safety would be reasonable to expect by monitoring an event using Web Hooks vs NetServer Service Events?

I know that Christian Mogensen was quite clear in his ExpanderWorld-talk about Zapier, that the intent of that functionality was not for major integrations. I don't remember his exact words, but my interpretation was that he was telling the audience that, this is a pretty reliable notifier, but it isn't transactional. But Christan are welcome to clearify his current opinion on this, if he is reading this. :)

As you don't "own" and can verify the actual transaction, I would be reluctant to rate this kind of monitoring as a transactionally safe and "true" monitoring method.

In this specific case, I suppose that I would rely more on a NetServer Service Event-solution than a WebHook-solution, as you monitor nearer the source and are not exposed to potential network mishaps. Though, WebHooks have the advantage of being Online/Onsite compatible and might give more flexibility solution wise.

 

Best Regards

Marcus

Av: Marcus Svenningsson 26. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

HI Anders,

My answers today always weigh our constant maneuvering towards online. With respect to compatibility, web hooks cover your use case and work in both on-site and on-line environments. They are well-defined events that will reliably send all subscribers notifications when events occur. The information that is send is minimal. It tells you what happened at the created|updated|deleted level, the identity of who was changed, and main fields pertaining to the event. It does not provide any entity data. You must use the identity key provided to look up any additional details you may require for additional processing/logging. To perform responsive api calls, you will need a means to manage credentials to perform subsequent actions.

With respect to NetServer Service Events (NSE)... They are extremly powerful in that you get the entire entity of interest, you never really know what event will be raised by webapi calls, or actions performed in the mobile/web application. That said, I published the Event Generator Utility on github to demonstrates how to create all NSE's, and show how to use Sysinternals DebugView application to monitor what events are being raised when a NetServer instance is invoked. Another benefit of NSE's is the events are raised in the content of the user, so it's trivial to know everything you may need to know about the use who raised the event.

There are other very low-level alternatives for on-site installations, but are not well documented, i.e. no tutorials or how-to guides. Maybe something for Expander World 2020?

  • Create a custom webhook plugin
    • receive notifications from pre-defined events and process in NetServer
  • Create a custom soft-trigger plugin (which the webhook implementation depends on)
    • subscribe to any table changes in the SuperOffice database, similar to database triggers.

None of these techniques are transactional. Transactional implies an exchange of messages between a sender and a receiver where each take turns to send or receive messages. They are the traditional publish/subscribe communication model. There is no opportunity for receiver to intrinsically influence the senders behavior.

If there is ever a chance this customer will migrate to the cloud, webhooks are the obvious choice.

Best regards.

Av: Tony Yates 26. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

Webhooks are triggered by all the web service methods, so a AppointmentAgent.SetCompleted, AppointmentAgent.SaveAppointment, Appointment.Accept all trigger the Appointment webhook.

NetServer Service scripts are per method, so you would need many scripts to intercept all the different methods that can save or update an appointment:

  • AfterSetCompleted
  • AfterSaveAppointment
  • AfterAccept

Webhooks are definitely the way to go.

 

Av: Christian Mogensen 26. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

...and what about the Bulk Update-feature? :)

Will the changes executed by the BulkUpdate trigger the expected WebHook-events or not?

/Marcus

Av: Marcus Svenningsson 26. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

I think I might just be able to answer this, since I wrote the BulkUpdate engine...
It is based on the Entities objects like Entities.Contact in SoDatabase.
No service layer is involved so I suspect that means no events.

The service layer facade used by the web client is merely passing on a bulk update job description.

This is not going to change. Well not in my time anyway :-)

Note that a user requires a functional right to be able to use it so you can disable it for most/all users.

Conrad

Av: Conrad Weyns 26. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

Entities and Row object changes are caught by the NestedPersist mechansim that underlies webhooks - so the bulk updates will fire webhooks.

Av: Christian Mogensen 27. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

Hi Conrad,

Thanks for the clarification!

From a developer/integration perspective, I think it is important to make it very clear that possibly expected change-events will not get triggered when using the BulkUpdate, as it is important information for the ones that are thinking on building log/monitoring solutions.

If using the BulkUpdate via the API, you might be able to handle this separately using some workaround at least.

I have a case right now where we are looking on building an automated GDPR anonymization function where using the BulkUpdate via the API might be a more effective way of updating multiple records in a batch.

/Marcus

Av: Marcus Svenningsson 27. sep 2019

RE: How to catch CRUD operations performed by built in REST-API

Oh, Christian you were faster than me. :)

Ok, that's positive news!

If I'm not mistaken, the other post I read about, might actually have been related to BulkUpdate and the Zapier-connection. Is there any difference there or are the Zapier-app based on our Web Hooks and therefore should trigger the same way?

Might it have been differences in this workflow in an earlier version of the Zapier App, so a state valid at the forum post date might not be valid anymore? It could also be the case that the assumption in that post, was just plain wrong and the problem might have been connected to something else.


Best Regards
Marcus

Av: Marcus Svenningsson 27. sep 2019