jde bssv consumer xml/json

nkuebelbeck

nkuebelbeck

VIP Member
we've got a project where we need to integrate with a third party web service and the third party only accepts json objects as the payload in their restful api. from what i read, all i have access to in the JDE C bsfn is the Xcerces XML parser.

As I see it I've got four options

1) write the json string by hand in C (i just threw up a little)
2) send xml to the bssv consumer and have the java convert xml/json before payload is delivered and after the the response, before it goes back to the calling C bsfn. (i don't even know if this is possible)
3) jde c has a json parser?
4) just won't work

Anyone have any experience with a bssv consuming a json web service?
 
I believe Jackson is a 3rd party java lib to help working with json. But you could build it by hand

Craig
 
Don't see why not. It's just a simple http request/response you can do in any POJO. You're just going to convert the json response back into the value object (if I'm thinking correctly)

I wonder if jDeveloper has a wizard for consuming a RESTful service?

Craig
 
Yup, i understand what restful web services is, there is just no mention of it. BSSV seems to want to do all the fun things involved in WSDL (security in the payload). Where as most restful services rely on http headers for auth. I haven't been able to find any mentions of BSSV consuming a NON-wsdl. I'm going to open a SR and see what they say
 
I wonder if jDeveloper has a wizard for consuming a RESTful service?

Craig

There is, in JDev 12c at least. Under Business Tier|Web Services|RESTful Client and Proxy just like there is for SOAP. I have not used it yet but I assume that it would work similar to the SOAP equivalent. Like you effectively stated all ready, the interface between the calling C BSFN and the BSSV is the same regardless of what you actually do in the BSSV. You could use a consumer BSSV to do anything you want... it doesn't have to actually consume a web service.
 
NO Rest-based web services per support

E1: BSSV: Getting Started with setting up and running E1 Business Services (Doc ID 967281.1)

"Note: A comprehensive set of samples are also provided as part the the E1 installation. These samples are available in the following location on your Logic Server: "\ddp\system\classes\samples.
BSSV only supports JAX-RPC and JAX-WS standards. Rest-based webservices are not supported."
 
Correct. either of them are not supported nor certified.

=======
Provider
=======
Option1: Youou can use AIS server to process JSON request instead of BSSV. This solution is totally different than BSSV solution.
Option2: Please go through the below link, It explains how to consume RESTful Services to some extent:
http://www.oracle.com/technetwork/articles/javase/index-137171.html
.
Also you may go through the "Restful" sample delivered as part of the JAX-WS
Framework: https://jax-ws.java.net/2.2.7/

--> this is a suggestion and not supported by JDE team.

=======
Consumer
========
There is no workaround for it. must be an enhancement request. I have found a record saying that the strategy team's decision that they are not planning to support it at this time.
I'm still looking for an enhancement BUG number. If I cannot find it, then I'll enter one.

Please let me know if you have any questiosn.
Thanks,
Nami
 
The workaround I would follow is a little complex but effective. I am ASSUMING that you have a middleware (Mulesoft, OFM, WebSphere) integrated with your JDE. Design your outbound BSSV to talk with your middleware. And have a JAVA bean or similar program receive the middleware request and interface with the 3rd party RESTful service. Your BSSV-middleware can use internal certificates but the external interface needs to use proper SHA2/TLS etc. cert assuming the RESTful service demands so. The java program(s) are the key to this integration.

AIS supports inbound REST/JSON only. BSSV supports only SOAP. My prediction is that future tools release might allow AIS based outbound REST/JSON calls but not with BSSV. This is because Oracle gets to earn extra money by pushing the AIS license. So far, the penetration is not that great. :p

Best...
Ron

PS: I am not sure if there are other ways to do it more elegantly. You may search for other interoperability options. But doing it via your middleware takes a lot of burden off the JDE development side.
 
The workaround I would follow is a little complex but effective. I am ASSUMING that you have a middleware (Mulesoft, OFM, WebSphere) integrated with your JDE. Design your outbound BSSV to talk with your middleware. And have a JAVA bean or similar program receive the middleware request and interface with the 3rd party RESTful service. Your BSSV-middleware can use internal certificates but the external interface needs to use proper SHA2/TLS etc. cert assuming the RESTful service demands so. The java program(s) are the key to this integration.

AIS supports inbound REST/JSON only. BSSV supports only SOAP. My prediction is that future tools release might allow AIS based outbound REST/JSON calls but not with BSSV. This is because Oracle gets to earn extra money by pushing the AIS license. So far, the penetration is not that great. :p

Best...
Ron

PS: I am not sure if there are other ways to do it more elegantly. You may search for other interoperability options. But doing it via your middleware takes a lot of burden off the JDE development side.

Thanks for this. We've opted for a less streamlined(import/export csv) integration for now. If the third party app takes off we'll likely be writing non-jde middleware to do the integration. Shame.
 
I could have sworn this has come up before on jdelist and other people have all ready done this (I know, Google...).

We are in the middle of a POC with a 3rd party vendor to integrate JDE to their system via SOAP based WS. We are probably going to do another POC with another vendor that only exposes their APIs via REST. Myself and one of my developers are working on figuring out how to call RESTful WS from a consumer BSSV. My developer worked on this some yesterday and I think he is pretty close. I will post back if we figure anything out... although I am pretty sure someone around here has all ready figured it out.
 
Brian, thanks for posting this. I'm struggling to understand the technical reason why this "can't be done" according to Oracle. Looking forward to your response (I was gonna build something this weekend to test ... not anymore) If anyone has a reason why we can't do an HTTP request/response within a BSSV, please explain.

thanks
Craig
 
Technically it wouldn't be a lot of work to grab the xml request in the bssv and make it work. You'll have to use some third party librarys for the xml/json fun.

some "jde" reasons
1) no native JDE C way to make JSON(making it yourself in a string doesn't count)
2) jde softcoding conforms to the wsdl authentication in the payload, not the http header. so manipulating the http header would need to happen in the bssv consumer in a new way
 
Technically it wouldn't be a lot of work to grab the xml request in the bssv and make it work. You'll have to use some third party librarys for the xml/json fun.

some "jde" reasons
1) no native JDE C way to make JSON(making it yourself in a string doesn't count)
2) jde softcoding conforms to the wsdl authentication in the payload, not the http header. so manipulating the http header would need to happen in the bssv consumer in a new way

1). From the C BSFN perspective, this shouldn't change. Your interface from the C BSFN to the BSSV and then from the BSSV to the C BSFN will still be the same XML that gets marshalled/unmarshalled to your Java value objects. It is in the Java code inside of the BSSV where you have to marshal/unmarshal the value objects to/from JSON and I believe the JDev 12c wizard should handle all this for you... somehow????
 
also agreed. In the end it's HTTP POST/GET/etc etc

short sided implementation in my opinion. SOAP/WSDL was supposed to be THE thing back when it was dreamt up and designed.

Turns out it more complicated then 99% of people need for actual use cases which is why JSON/REST has found a foothold. (JDE AIS even went JSON/REST)
 
Back
Top