Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Building Better Bridges

Building Better Bridges

The most challenging integration efforts frequently involve integrating enterprise resource planning (ERP) or customer relationship management (CRM) systems with new and existing custom applications.

These enterprise software applications often have proprietary architectures and complex APIs, and use proprietary programming languages unfamiliar to the mainstream developer community. However, some enterprise software vendors are attempting to make the integration effort more approachable. Using XML and Web services, these vendors are attempting to bridge the gaps between their respective products and the world around them.

In the first installment of this two-part series (WLDJ, Vol. 1, issue 10), I looked at how the Java Messaging Service (JMS) and PeopleSoft 8.4's Integration Broker (IB) technology can be used to integrate PeopleSoft and J2EE applications. In this article, I will explore how Web service technology can be used to integrate PeopleSoft with J2EE applications. These concepts can be extrapolated to integrate PeopleSoft with any application capable of manipulating XML content and maintaining an HTTP connection. This opens the doors of integration to a wide range of environments such as J2EE and .NET.

Web Services - A Matter of Definition
For PeopleSoft Inc., the definition of a Web service is clear - it is an application component that can be accessed using XML messages over an HTTP connection. This definition means that Web services are inherently open and accessible over the Internet and across corporate intranets. In addition, they are accessible to a wide range of technologies and platforms.

XML and HTTP are the essential ingredients of any Web service. Additional standards, such as Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL), improve the consistency and accessibility of Web services by standardizing the description of Web services and the format of the messages they exchange. However, SOAP, WSDL, and Universal Description, Discovery, and Integration (UDDI) - a protocol for cataloging, publishing, and locating available Web services - are not requirements for Web services. Instead, these protocols mainly enhance the overall usability of Web services.

I will describe two scenarios for integrating PeopleSoft and J2EE applications. The first describes how a PeopleSoft application can invoke a WebLogic Server (WLS) 7.0-hosted Web service. The second describes how a J2EE application can invoke a PeopleSoft Web service. Both scenarios make ample use of XML and HTTP, while only the first uses SOAP, and neither explicitly uses WSDL. For the sake of simplicity, neither will use UDDI. Rather, it is assumed that both the PeopleSoft and J2EE clients know the specific names and locations of the Web services they desire.

Example 1: Invoking a J2EE Web Service from a PeopleSoft Client
In this scenario, I used a very simple Web service that is implemented as a session bean. WebLogic's servicegen Ant task automates the process of turning Java classes, session beans, and message-driven beans into Web services. Hence, the work involved in providing and publishing the Web service is considered trivial and thus, in the interest of time, will not be described. Instead, I'll first focus on the IB definitions that are required to support the integration. Next, I'll explore the actual client-side PeopleCode required to invoke the Web service.

As described in my first article, a number of key IB definitions must be created in order to support an integration scenario. In this scenario, PeopleSoft is synchronously invoking an HTTP-based Web service that resides on an external system. Since a synchronous invocation implies both a request and associated reply, I'll first define the request and reply messages, JKK_SBINFOFACADE_SOAP_REQ and JKK_SBINFOFACADE_SOAP_RESP, using the PeopleTools Application Designer environment. Next, an IB node must be defined to represent the external system, and its associated target connector must be PeopleSoft's HTTPTargetConnector. This node, JKK_WS_TARGETNODE, and its associated HTTPTargetConnector properties are shown in Figure 1.

The HTTPTargetConnector states that an HTTP POST to the URL, http://wls-01:7001/web_services/SBInformationFacade, is needed to reach the JKK_WS_TARGETNODE IB node. This URL is the address of the WLS-hosted Web service. Next, an outbound synchronous (outSync) transaction must be defined on the JKK_WS_TARGETNODE node, specifying JKK_SBINFOFACADE_SOAP_REQ and JKK_SBINFOFACADE_SOAP_RESP as the request and reply messages, respectively. Collectively, these IB definitions will support the synchronous exchange of messages with the WLS-hosted Web service, using an HTTP connection.

Next, I'll address the specific tasks required to create the PeopleCode Web service client. We begin by using the deployed Web service's home page (located at the URL listed above) to examine the SOAP messages exchanged when a Web service operation is invoked. For this example, I'll focus on invoking the getID Web service method, which simply generates and returns a unique identifier to its caller. Figure 2 illustrates the results of invoking getID() using the Web service home page.

This information can be used to implement the PeopleSoft client. Since PeopleSoft has no JAX-RPC equivalent, the client cannot readily make use of a Web service's WSDL description. Hence, in order to invoke the getID() operation, the PeopleSoft client must explicitly create, send, receive, and interpret the SOAP messages shown in Figure 2.

PeopleSoft provides direct support for manipulating SOAP messages and XML documents, via the SOAPDoc and XMLDoc PeopleCode classes. To invoke the getID() operation, the client must create and then send an appropriate SOAP request document to the Web service. These steps are illustrated in the PeopleCode program in Listing 1.

The special PeopleCode functions, CreateSOAPDoc() and ValidateSOAPDoc(), are used to create and validate SOAP documents. Both methods operate on instances of SOAPDoc, a special PeopleCode class that encapsulates SOAP documents.

SOAPDoc allows clients to specify and retrieve the fundamental elements of a SOAP document, including its envelope, body, method, and associated parameters. Upon inspecting the SOAP request and response documents in Figure 2, we learn that the actual SOAP method for invoking getID() is, in fact, getID(). Hence, after adding the mandatory envelope and optional body to the SOAP request document using SOAPDoc's AddEnvelope and AddBody methods, I used AddMethod to specify "getID" as the target Web service operation. Since SOAP methods can represent a request or response, AddMethod's second calling parameter can be used to specify which role to use. Supplying "1" means the method is a request, which will ultimately generate a getID element in the SOAP document (ex: <getID></getID>). However, supplying a "0" means the method is a response, which will be rendered in the SOAP document using the generally accepted practice of appending "Response" to the name of the method, eg., <getIDResponse></getIDResponse>. If getID() took arguments, they could be specified using SOAPDoc's addParm(parmName, parmValue) method, in which parmName is the formal name of the parameter or "part" (as specified in the Web service's WSDL description), and parmValue is its value.

The next step is to send the SOAP request document to the Web service using either the synchronous SyncRequestXmlDoc IB function or its asynchronous counterpart, PublishXmlDoc. Both functions will send a given XML document, under a specified message name, to a specified IB node. In Listing 1, the SOAPDoc's XMLDoc component is first extracted before being sent as a JKK_SBINFOFACADE_SOAP_REQ message to the JKK_WS_TARGETNODE IB node. In turn, IB will send the SOAP request document to the specified URL, effectively invoking the Web service that resides there. Once the Web service getID() operation completes, IB will convey the results to the PeopleCode client.

Finally, the PeopleCode client will use a SOAPDoc instance to capture and interpret the Web service's response. Because a response can contain multiple SOAP parameters (i.e., for the out and in-out parameters of a Web service operation), the SOAPDoc class provides GetParmName and GetParmValue methods to determine the name and value of specific parameters. In our scenario the getID() operation (and getIDResponse SOAP method) only returns one parameter, an integer named result (see Figure 2). So, for our purposes, we can assume that the first parameter name and value correspond to the result and associated value returned by the getID() operation.

Example 2: Invoking a PeopleSoft Web Service from a J2EE Client
PeopleSoft functionality can be exposed as Web services using an Inbound Business Interlink. Business Interlinks are integration mechanisms that enable external systems to perform component-based, real-time integration with PeopleSoft systems. Business Interlinks accomplish this by creating synchronous transactions that facilitate the real-time exchange of data between PeopleSoft applications and external systems.

Inbound Business Interlinks provide Internet Scripts (or IScripts), which are specialized PeopleCode programs that behave much like J2EE servlets. An IScript resides on the PeopleSoft server and is capable of exchanging XML data with external systems using HTTP. Incoming HTTP requests can originate from a Web browser or a client program communicating via an HTTP connection. An IScript definition spans both the PeopleSoft application and Web servers. The application server portion, which must be defined first, contains the actual implementation or business logic of the IScript, and is written in PeopleCode. The first step is to use the PeopleTools Application Designer to create a record, called a Web Library, or WEBLIB. WEBLIBs, which are roughly analogous to Java Archive (JAR) files, can store collections of IScript definitions within the Field Formula (FFO) fields of their columns. These records and columns, although similar to the definitions discussed in the first article, are not necessarily intended to store application data. Rather, they simply provide a convenient place to house and organize IScripts. Figure 3 illustrates the WEBLIB record, WEBLIB_WSILINK, which is used in our example.

The Web server portion, defined via the PIA screens, links the IScript to a service name, and stores this linkage in an XML registry. The service name will become part of the URL that any HTTP client (including a Web browser) must use in order to access the IScript. The definition and linkage of this service name is shown in Figure 4.

PeopleSoft's rich security model is at play here - ensuring that only properly authorized clients can access an IScript and the business components it uses. You can use the PeopleTools Security PIA screens to enable client access to an IScript and its WEBLIB, as shown in Figure 5.

Once the appropriate security settings are made, the URL can be used from a browser or client program to invoke the IScript. The IScript can be written to accept and return information in XML form, effectively making it a Web service.

An IScript, like a J2EE servlet, has programmatic access to the incoming HTTP request and outgoing HTTP response. As such, an IScript can read and use the contents of the incoming request object to guide its operation. For example, an IScript could take one or more arguments. These arguments could be passed through the IScript's URL, making them available via the request object. The IScript can respond, much like a J2EE servlet, by populating the supplied response object, which is ultimately conveyed back to the HTTP client. For our example, I'll create a simple IScript-based Web service that returns a list of known general ledger accounts, given some selection criteria. Listing 2 shows the PeopleCode implementation of the IScript, which ultimately creates and returns to the HTTP client an XML document containing the desired accounts.

As shown in Listing 2, the special PeopleCode variables, %Request and %Response provide access to the HTTP request and response objects, respectively. Additional PeopleCode classes, like SQL, are used to query the account data, while XMLDoc and XMLNode classes are used to build the XML document containing the account data. Ultimately, this Web service can be tested from within a Web browser by simply jumping to its URL. Figure 6 shows the result of invoking the Web service from within a browser. This same data would be returned to a programmatic HTTP client.

It is a fairly straightforward matter to automate the invocation of the Web service using an HTTP-enabled J2EE client. Listing 3 shows the Java implementation of a simple client, which first uses a URL to address the targeted Web service. Next, the client program performs a simple HTTP GET operation in order to receive the response. Finally, a mixture of JAXP and DOM invocations are used to parse and process the general ledger accounts returned from the Web service.

These articles only scratched the surface of integrating PeopleSoft with external systems. Issues such as security, scalability, and integration using various other protocols are complex and require far too much time to cover in this medium. However, these articles do shed light on the incredible advancements PeopleSoft has made to this critical aspect of systems integration.

More Stories By Joseph K. Krozak

An expert systems architect with over fifteen years of full lifecycle software engineering experience in various applications including banking, supply chain management / manufacturing, law, insurance, and telecommunications. I have spent years mentoring management and development teams on the architecture, design, implementation, and planning of large-scale, distributed, enterprise applications.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...