REST Web Service Policies should support JSON format

Idea ID 1641157

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?


20 Comments
Super Contributor.. Super Contributor..
Super Contributor..

This can indeed be merged with the other topic.

Thanks
Jim

Micro Focus Expert
Micro Focus Expert

Thanks @JimDS , will do so and please track the progress in the other idea.

Regards,

Moderator, OpsB IdeaX

Super Contributor.
Super Contributor.

I developed a working JSON "front-end" or gateway (in NodeJS) that transforms incoming events into XML format for OpsCx ingestion.  It has been and continues to be a major effort, having starting with zero JavaScript experience.  This service is co-located on my OpsCx servers.

I agree with @JimDS ...  Managing Policies for Event ingress seems more approachable around here as well.  We don't do any topology discovery from tools, instead rely on external CMDB source for that.  At some point in the future event backsync may be needed, but for us right now it is not a requirement.  I try to have central OpsCx cluster to receive events from all sources, whereas topo integration expects installing OpsCx on each source tool.  My team does not support most source tools -- these are managed by each SME team.

Also, fronting event ingress processing (esp filtering) by OpsCx has the effect of offloading much event processing from the core OMi complex.

There seems to be no event exchange standard in the world of web services.  At least, all potential event-sending tools I have run across seem to have unique format.  Often this format is fixed, unchangeable.  So the ability to re-arrange, transform, and filter such event content is a strength for OMi.  Doing this in a code-less way is much safer and more rapid, less labor to construct & maintain each integration.

Providing a generic backsync "codeless policy" method would be much harder for Microfocus to build, I imagine.  Due to wide variance in tools, it may not be feasible.

Valued Contributor.. Valued Contributor..
Valued Contributor..

I developed a python based endpoint for all the incoming JSON events that transforms them to XML. Supporting JSON would remove this step.

Super Contributor.. Super Contributor..
Super Contributor..

In the mean time, we also developed our own JSON->XML translator in Go.
But as @dbmobi says : a native JSON intake would remove this extra step.

Respected Contributor.
Respected Contributor.
Status changed to: Under Consideration
 
Frequent Contributor.
Frequent Contributor.

When should we expect a response

Respected Contributor.. Respected Contributor..
Respected Contributor..

Any update on this request?

Super Contributor.
Super Contributor.

Webhooks are an industry standard used by many cloud providers.  Please provide an update on Webhooks.

Trusted Contributor.
Trusted Contributor.

Hello @Mgoyal 

Any updates on this Idea? Thanks in advance.

Best regards.

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.