Is there any REST API to create a business rule?

[jak2018]

My requirement is, whenever an user select ServiceNow integration in my application I will be making a call to a Scripted REST API and from that scripted api I want to create a business rule on the table specified by the user. So that I can receive change notifications on my web hook. 

How can i achieve this?

Thanks in advance.

[Yifeng Zhang · Accepted solution]

a Business Rule(BR) is just a record in sys_script table. so really you are looking at calling the table API on the sys_script table to create a record,

in the BR record you can specify which table to assign to, so when you calling the table API, just specify the field with the sys_id of your target incident table. same with the scripts for the BR, it just stored in BR.script field I think.

[Yifeng Zhang]

But in honesty I don't think this is a good solution architecture where you create a BR for each user request on the table.. I would just create one BR that have a subscribe list of user and update that variable....

[jak2018]

I did not get you. Could you please elaborate? I am new to ServiceNow so I am not able to follow ur suggestion

[Yifeng Zhang]

ok, so from what I gathered you basically wanted to build a event listener for users.

some thing changed on some table you want export that information to the webhook.

And specifically each user only wants to listen to some tables, so this is a subscribe list, user subscribe to a list of tables.

In this scenario you wouldn't want to create new BRs for each user on each table, you gonna end up with a huge list of BRs and that means a huge amount of overhead and load on the server.

Now consider this,

Consider a script include, call it eventListener.

now on your tables just build one BR for each table which fires an event object when ever there's a change you want to monitor, to the eventListener.

and the event Listener handles dispatching event to your webhook, the eventlistener must have subscribe information, such as, 

"oh table 3 tells me there's a change in table 3, now let me see which users subscribed to this table".

Then the event listener sent out all this information to your webhook.

Now as for how you store this subscribe information, the correct way to do it is actually build a many to many table and defines subscription between user and table. Because, well it is a m2m relationship.

And the eventListener can easily just query this table to find it out.

But there are many ways to achieve this, you can store a list of table on the user record, store it in sysproperty (not recommende..), or database view maybe? but how ever you like really.

Anyway so this way you end up with one BR per table and one script include, much better than one BR per User/table.

You can do even better by using table inheritance where all your table inherit this parent table and the BR is on the parent table so you only having one BR in the end. This is possible because your BR is generic enough, it only wants to fire an event rather than handling the dispatching.