Webhooks

[Mike.Sheen]

A plugin which extends the REST API to add Webhooks is available from our docs portal.

It might be of interest to anyone doing integrations with Jiwa via the REST API - you can eliminate polling and have integration actions done instantly.

We'll probably bake it into the product later - but what the plugin provides is functional and will "Stop the polling madness!"

[SBarnes]

Great idea

Actually leaving it as a plugin might have the advantage that it can be extended such as in the case of other business logic objects that could be added to the system etc.

[Mike.Sheen]

Oh, we'll leave the logic as a plugin, but the creation of the tables and views it requires we'll build into the upgrade scripts, and also add some forms in Jiwa to manage Subscribers, subscriptions and messages.

Just trying to work out now an elegant way of filtering when a subscription gets a message (think only sales orders where it is a certain debtor) and also stripping out of the DTO irrelevant or sensitive info (think when adding a product, remove all customer specific prices, except those for a certain debtor).

One step at a time, I guess.

[SBarnes]

Hmm, interesting issues.

Could a new plugin interface be the answer, that would let code be added to actually do the serialisation as that would be incredibly flexible and have the default happen if there was no plugin, given the business logic object and subscriber similar to the generic setup calls on the current plugins i.e. a serialise function and can serialise function, either that or a template similar to emails?

[SBarnes]

Hi Mike,

What would be required to modify the the webhooks plugin so that it could call the Jiwa API itself, what I am talking about is an inter-company scenario of transmitting say sales orders including possible attached documents to a head office?

Obviously the main issue would not only be the transmission but the need to login first, also do all the necessary ServiceStack Dlls for the client also ship with Jiwa.

[Mike.Sheen]

Hi Mike,

What would be required to modify the the webhooks plugin so that it could call the Jiwa API itself, what I am talking about is an inter-company scenario of transmitting say sales orders including possible attached documents to a head office?

Obviously the main issue would not only be the transmission but the need to login first, also do all the necessary ServiceStack Dlls for the client also ship with Jiwa.

Hi Stuart,

Firstly, yes we ship with the ServiceStack dll's needed to use a ServiceStack client in a plugin.

If using webhooks, you won't need the SericeStack client, as it uses the ServiceStack HTTPUtils to perform operations on the subscriber API. HTTPUtils is a nice library ServiceStack made to consume non-ServiceStack API's - but can be used to also consume ServiceStack API's. The head office would need an instance of the REST API running, and the branch office also needs the REST API running with the Webhooks plugin enabled.

As for the authentication problem (head office REST API won't accept a sales order POST operation unless authenticated first), then a few lines of code to perform the auth step would need to be added to the plugin.

Then you'd add the head office as a webhook subscriber to the salesorder.created event in the branch office.

I imagine it should be quite straight forward. The only modification to the plugin (besides the aforementioned authentication) you may need is to alter/map some of the sales order fields - for instance, the branch office may have a different DebtorID/Account No for a customer to the head office - so you may need to set some property values of the sales order DTO before being sent (or you may choose to do the reverse, and map at the head office end).

As always, we're here to assist if you need specific guidance - so feel free to ask for assistance if needed.

An alternative to using webhooks is to not have the branch office configured with the REST API at all - just the head office - and a plugin in the branch office to hook into the Sales Order SaveEnd event to create a ServiceStack client, and perform the sales order POST operation against the head office REST API. This might be a simpler solution for you.

I'm hoping to publish a plugin using our REST API soon which performs inter-company transactions for a wholesaler-retailer type scenario - one where a PO for a particular creditor in the retailer database gets sent to the wholesaler as a sales order, and a PO Acknowledgement gets sent back to the retailer with any changes (price variations, product discontinued / superseded, and so on) and also create a GRN in the retailer in preparation for later activation.

It sounds like it doesn't quite match what you're after (branch sales pushed to head office), but some of the techniques used might be of interest.

Mike

[SBarnes]

Hi Mike,

Thanks for the feedback.

Interestingly some of the stuff you are looking at in the inter-company scenario I have had to perform in another system that I am familiar with it being needed quite often on a regular basis in recent times.

The other area which you find people seem to be keen on being able to do also, is take the ledger journals produced at the branch level and pass them up to a master / head office database for consolidated reporting purposes, of course most of this relies on the segments of the chart of accounts being setup correctly to support the reporting from the branches.

I am amazed at how often multiple financial entities seem now be common with a lot of smaller organisations.