Advanced JD Edwards Integrations using Business Services and External RESTful Web Services

A client came to us wanting to integrate a third-party system with their instance of Oracle JD Edwards (JDE), and was wondering whether their business services setup could do the job.

Since consumer business services are capable of consuming SOAP web services, and implementation of SOAP web services is simplified by importing its WSDL to generate method signatures, the request seemed deceivingly straightforward. Things became complicated when it was revealed we had to consume a RESTful web service, the latest iteration of web service technology to grace the World Wide Web.

This is because JD Edwards has yet to support consumption of RESTful web services using business services, meaning that the complex process of implementing a consumer business service immediately became far more complex.

This is what my team and I learned during the process.

The RESTful Craze

The increased demand for web services, as well as the advent of the Internet of Things, has pushed the boundaries of older technologies like SOAP and WSDL. To its credit, the service-oriented paradigm sufficed the demands of an ever-growing repertoire of programming languages and frameworks hungry for consumption of services over the web.

SOAP is reliable, secure, and has years of development congealed in robust APIs widely available online. But increased demand for web services far exceeded supply in terms of scalability and portability, and the protocol’s methodology started to show its age. Implementation and modification of SOAP web services is no laughing matter (at least if one wants to do it well), and its stateful nature is fundamentally incompatible with the needs of mobile devices due to power and connectivity limitations. The answer to SOAP’s problems was not just a new protocol, but a complete revamped architecture, where stateless, data efficient interactions were the business of the day. For the present, and for the foreseeable future, RESTful architecture is the answer to those problems.

RESTful web services’ usage has propagated exponentially these past few years and it is rapidly becoming the standard for interfacing systems over the web. It is reliable, portable, and focused on performance and scalability. Its stateless nature is perfect for the increased demand for mobile connectivity, because it frees users from maintaining open connections for interfacing, while requiring small amounts of data to be exchanged.

Having spent time developing both, I’m elated with its newfound popularity, thanks to its simplicity and adherence to the object-oriented mentality that drives us to develop not individual systems, but building blocks for overarching systems coalescing the work of multiple minds towards a single objective.

A Complex Task Became Far More Complex

There are tons of material all over the web that could show you how to accomplish the task of consuming a RESTful web service in a myriad of languages, with the right timeframe and technology. For my team, these factors were constraints: we had to use business services, and implementation had to occur within a small window of time. Several ideas came to mind throughout the whole process – some early on during conception and others while brainstorming about the ones that did not work well.

We first settled on formatting the data from JD Edwards by using existing functions for data formatting into XML strings, parsing that XML into a JSON string (REST architecture accepts XML, but JSON was requested), and using a Java API capable of consuming RESTful business services to upload the JSON-formatted data.

We tested our solution with a random public RESTful web service and it worked. We moved forward with confidence until we ran into our first issue: Java did not like the third-party system’s web service certificate and would not let us connect. Additionally, the XML API found in JD Edwards would produce a tag as a collection only when more than one element was found (no one told this function that single-element sets are still sets).

This became a problem when parsing it to the expected JSON, because the web service demanded a collection, and it refused to work with anything else. Still, our designed solution seemed solid and we plowed through them with grit, believing this was the big hurdle to overtake.

An example of the integration between a RESTful web service and JSON. Credit.

The Big Hurdle

Even when we overcame the local issues threatening our design, and we were ready to deploy our revised solution on the server, the reality of the complexity of developing consumer business services revealed itself with a force.

Running the consumer business service by itself on JDeveloper is half the battle. We ran into several issues when trying to replicate our local tests on the server, ranging from struggling to establish a connection between the Enterprise server and the Business Services server, to being unable to catch an unhandled exception within the RESTful Java API we imported for the job. Even when we finally got both servers talking to each other, we later found data being passed incorrectly between them, due to a single misspelled tag name.

Additionally, we had to deal with a myriad of subtleties found within the third-party’s system, such as undocumented data constraints or minor bugs with its functionality. We could deal with all but one issue to overcome this big hurdle, and time was running out.

The thrown unhandled exception within the Java API we imported was basically coming from a black box. It occurred only on the server and not locally, and logging it was difficult. A critical decision was made: we had to redesign most of our solution.

It required training ourselves on doing something on Java and Web Logic with only hours to spare. This meant starting almost from scratch with a fraction of the time left. It was a big leap of faith, as there was still a few unknowns, but, having learned so much from just a few days of work, we retained our focus and eventually got our new solution to work.

A Big Leap of Faith

There is a point in any project gone awry where the gift of hindsight becomes a curse; it can take you down a path you don’t want to pursue. While the world around us was getting ready for the winter holidays, we were starting almost from scratch to deliver the solution we were committed to produce.

The third-party API we chose to consume RESTful web services was not getting along with the Web Logic server when promoted through a business service. But it occurred to us that, having direct access to this instance of Web Logic, we could test the API directly by creating a standard SOAP web service. Time was running out and we had never created a web service on Java (using Web Logic to compile it and deploy it), so we trained ourselves within a few hours and finally got a simple web service working using the third-party API.

We now knew how to create a SOAP web service on Web Logic capable of consuming an external RESTful web service, and we already knew how to create a consumer business service to consume a SOAP web service, so our only answer at the time was to marry both ideas to produce a scalable solution that could work.

It was admittedly practical and not ideal, but the solution worked as expected. Its odd design yielded some unexpected benefits, such as empowering our logging ability and simplifying scalability by decoupling custom logic (specific to Java and JSON) from the unwieldly process of demoting and promoting a business service. But more importantly, it left us with a tale to tell and lessons learned to spare.

On a personal note: the one lesson one must learn from this experience is that ‘not knowing’ is not necessarily a barrier; it can also be an opportunity.

Lessons Learned

As much as I am a fan of narrative, we are still a technically-minded bunch, so here is a brief list of the most important lessons we learned from this process:

• First and foremost – be wary of assumptions. When it comes to business services in JD Edwards, it is safe to expect a business service to behave differently between the local client and the server. Test a simple version of your customized solution locally and on the server before fully developing the final version of your solution.
• Stick to strict naming conventions when interfacing systems. Developing consumer business services requires coding on Event Rules, C++, and Java, and data transfer utilizes XML and JSON. A single misspelled or mismatched tag name can and will disrupt the interfacing functionality, and it can become very difficult to debug these types of issues when your solution is fully developed.
• Define your test cases carefully and thoroughly. There is a myriad of XML and JSON APIs that, even though they often work together well, might not behave in the same way when it comes to producing collections, empty fields, or nested structures. Define and test simple versions of all cases to avoid running into errors that can become difficult to debug in the future.
• Prior to the design phase, make sure you know THEIR system as you know YOUR system. When creating solutions to interface several systems, even the perfect solution can falter if it is solely based on how the documentation states the third-party system works. Study their system. Play with their system. Attempt to break their system (leave the mayhem for the sandbox!). Know their system well before designing your solution to avoid having to redesign in the future.
• Know your tools well. JD Edwards’ Business Services uses WebLogic to generate and deploy web services, and, for most solutions, developers are not required to use WebLogic directly. But knowing WebLogic can only empower your ability to deliver custom solutions to solve complex problems, putting you ahead of the game. It is a full-fledged application server that has powerful interoperability capabilities. Learning to use directly and indirectly will help you be a better business service and web service developer
• Never feel you know enough. When it comes to making decisions on design and implementation, it is important to be confident on the path you are taking. But that doesn’t mean your design couldn’t be better, or that your implementation couldn’t follow a better methodology. Feeling confident in your knowledge about a technology helps you deliver the same solution for the same problems, but learning something new helps you deliver new solutions for new problems. The field of computer science never stops evolving, and neither should you.
• Not knowing is not an excuse for not doing. It is easy to crumble when you feel you don’t know how to do something you are required to do. It is important to remember that often what’s really hindering you is not having the right attitude. Give yourself the chance to learn, experiment, and discover on your own. Remember that every existing solution was originally conceived when there were no tutorials to follow and no guidelines to prepare. Give yourself the chance to innovate.