Community in read only mode June 18 & 19
This community will be set in READ ONLY mode for a while on Tuesday June 18 into Wednesday June 19 while we import content and users from our Micro Focus Forums community site. MORE INFORMATION

REST Web Service Policies should support JSON format

REST Web Service Policies should support JSON format

Briefly describe your idea
Some sources only send data in JSON format. Current OA REST Web Service policies only understand XML format. Enhance this policy type to accept inbound data in either JSON or XML formats.

Why is this important, when it would it be used
Need to understand JSON format

If you were designing the solution, how would  you do it?


15 Comments
Micro Focus Expert
Micro Focus Expert
Status changed to: Waiting for Votes
 
Kip Holliday Super Contributor.
Super Contributor.

Since there is currently no built-in 'event receive' policy for JSON data, I am compelled to consider one of these approaches:

1. Create custom code at the sender side to transform the JSON into XML before sending to OpsCx.  But so far I have at least two candidate tools for JSON sending, so next option is more likely...

2. Create a script (possibly in Node.js) hosted onboard the same server as OpsCx to act as a 'service proxy' -- transform incoming JSON to XML before passing it to the OpsCx listener for XML.  Of course response must be proxied as well.

3. Use an industry standard web service appliance such as Datapower.  Probably this would avoid custom coding (and testing, maint, etc).

I seem to recall reading that the built-in web service listener for XML policy can only have a local self-signed certificate, not possible to apply a publicly trusted cert.  With options 2 & 3, I'd have the option to run https and provision any cert there.

Has anyone else tried one of these workarounds?  Good or bad?

Stijn_COL Respected Contributor.
Respected Contributor.

Hi,

It would be nice if the policy would support out of the box both types (xml and json).

Stijn

 

Super Contributor.. JimDS Super Contributor..
Super Contributor..

The API that can be used now to let any 3th party application generate alarms in Operations Bridge is not flexibel and modern. It still uses XML for example. All modern applications are using JSON.

I get a lot of requests of internal customers, just to provide a webhook on which they can just send their alarms into the OpsBridge.

Please vote 🙂

Micro Focus Expert
Micro Focus Expert
Status changed to: New Idea

Hi,

Can you pleases share your use case examples behind "just sending the alarms into OpsB"? Typically, our integrations to bring 3rd party events into OpsB also involves topology integration and event updates/backsync. Also, which API are you referring to? Operations Connector supports multiple ways to integrate events into OpsB.

Thanks & Regards,

Moderator, OpsB IdeaX

Super Contributor.. JimDS Super Contributor..
Super Contributor..

Hi,

We have also uCMDB running, so topology is most of the time coming from that integration.
As example I can give Prometheus, but there are a lot other tools (also in house developped applications) that can generate alarms, and the easiest way is just to send them to webhooks.

I know that there are products like Streamweaver to do the bidirectional integrations. But for some products we don't need all of that. Just webhooks to receive alarms.

The API I'm refering to is the events_list API

Thanks
Jim

Super Contributor.. JimDS Super Contributor..
Super Contributor..

Some extra comment I can add to this post :

Using the events_list API, you don't have any control over what is sent in. There is no policy validating and manipulating the event.

Microfocus has build a webhook solution in the latest MS Azure management pack. So my question is : make such a webhook generic and well documented so that any other application can just send alarms to it. The one developed for Azure is Azure specific.

 

Thanks

Micro Focus Expert
Micro Focus Expert
Status changed to: New Idea

Hi @JimDS ,

Thanks for submitting the idea. To better understand the requirement, could you please clarify the following points:

1. are you asking for a webhook interface to submit events in JSON format?

2. when you say "Using the events_list API, you don't have any control over what is sent in. There is no policy validating and manipulating the event", what kind of control are you referring to? These events pass through event channel in OBM and there you can use EPI scripts to manipulate the events.

Regards,

Moderator, OpsB IdeaX

Super Contributor.. JimDS Super Contributor..
Super Contributor..

Hi

JSON would be a huge step forward.
I'm again refering to the webhook that was created for Azure Log Analytics integration. There is a policy running on the agent where the webhook is running. In that policy you can put rules, fill or manipulate values based on those rules, create or drop events based on conditions, etc.... Like you do with all other policies running on agents of BSMC. 

I know you can do some kind of manipulations in EPI scripting, but not as easy as you can with policies. Our operators write and maintain policies, they don't do EPI scripting.

Thanks

Jim

Micro Focus Expert
Micro Focus Expert

Hi @JimDS ,

I have discussed this with Azure team and i understand its primarily the ability to consume JSON data stream. We already have rest webservice listener policy that can be used to feed xml data to OBM so your contention of being able to use a policy vs EPI script is already taken care of. But yes, today, we do not consume json data in this policy.  So, then the request would be that rest webservice policy should support the json format data, is that right? Is yes, then please take a look at the following idea:

https://community.microfocus.com/t5/Operations-Bridge-Idea-Exchange/REST-Web-Service-Policies-should-support-JSON-format/idi-p/1641157?advanced=false&collapse_discussion=true&filter=location&location=idea-board:OpsBridge_Idea_Exchange&q=REST%20JSON&search_type=thread

If you agree then I would like to merge the two ideas. If not, then please specify what else is missing.

Thanks & Regards,

Moderator, OpsB IdeaX

 

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.