Webhook Messages gives dates as unix timestamps

[Joe.Thorpe]

Apologies for posting again about Webhooks

Webhook Messages provide dates as WCF Dates:
"InvoiceInitDate": "\\/Date(1656574620530-0000)\\/",

Power Automate expects ISO8061, as do many C# tools to be honest. Both REST API responses and XML export from JIWA use ISO8061, so i'm curious why Webhooks don't.

I can see where it's configured in RESTAPIPlugin.Configure():
ServiceStack.Text.JsConfig.DateHandler = ServiceStack.Text.DateHandler.ISO8601;

I've just added it to BusinesLogicPlugin.Setup(), which is working.

Cheers,
Joe

[SBarnes]

Hi Joe,

The reason that the web hooks are not using that date format is as you rightly determined it is not set in the business logic work space i.e. in the client, the way the web hooks work is that on certain events the business logic in the client or any application it serialises itself and then makes a call to the ServiceStack extension method toJson that actually turns the object into Json which is why your change is working.

This is then posted to an endpoint on the REST API itself that does the sending and logs things to the appropriate tables namely SY_WebhookMessage and SYWebHookMessageResponse and handles all the possibly necessary retries etc.

My only other comment is you are best not to actually change the REST api plugin, as this could become a problem during upgrades but rather you should create a new plugin and add references to the appropriate ServiceStack libraries from Jiwa's program directory and to avoid needing to add all the business logic references that the REST API has to keep them in sync simply just put the line inside the set up call for the Application plugin instead as it only needs to be called the once any way.

By doing this you'll make future upgrades easier and not need to apply any custom changes to the new version.

[Mike.Sheen]

Logged DEV-9385 to make this standard.

[SBarnes]

It's worth noting mentioned here https://docs.servicestack.net/customize ... n-settings that according to the documentation this can be overridden on the query string for all services.

[Mike.Sheen]

It's worth noting mentioned here https://docs.servicestack.net/customize ... n-settings that according to the documentation this can be overridden on the query string for all services.

Unfortunately I don't think that will help in this case as there is no query string to modify for the webhook origin. But yes - it is worth noting that for normal requests to the API there are a bunch of overrides possible via the query string parameters.

[SBarnes]

I was mentioning it for service calls in general and not web hooks and more about whether or not you want properties of default values to be included which is one that customers have asked about as well as the other options mentioned but yes you are right I should have been clearer with the comment offered.

[Joe.Thorpe]

Hi Joe,

The reason that the web hooks are not using that date format is as you rightly determined it is not set in the business logic work space i.e. in the client, the way the web hooks work is that on certain events the business logic in the client or any application it serialises itself and then makes a call to the ServiceStack extension method toJson that actually turns the object into Json which is why your change is working.

This is then posted to an endpoint on the REST API itself that does the sending and logs things to the appropriate tables namely SY_WebhookMessage and SYWebHookMessageResponse and handles all the possibly necessary retries etc.

My only other comment is you are best not to actually change the REST api plugin, as this could become a problem during upgrades but rather you should create a new plugin and add references to the appropriate ServiceStack libraries from Jiwa's program directory and to avoid needing to add all the business logic references that the REST API has to keep them in sync simply just put the line inside the set up call for the Application plugin instead as it only needs to be called the once any way.

By doing this you'll make future upgrades easier and not need to apply any custom changes to the new version.

Thanks Stuart, it didn't occur to me that it could be done from a separate plugin, i'll give that a shot. Thanks for your help!

[Joe.Thorpe]

Logged DEV-9385 to make this standard.

Great! thanks Mike