Implementing ESB Processes with OpenEdge and Sonic

1
Implementing ESB Processes with OpenEdge and
Sonic
Frank Beusenberg
Applied Technology Consultant
2
Agenda
Developing Business Processes

• Technology Overview
• Developing a Business Process from Start to Finish

3
Audience Expectations

• Understanding of tools and technologies used
• Familiarity of thought process in creating a
  business process
• Complete script of the demo shown

4
Products Used

• OpenEdge 10.1B02
• OpenEdge Architect
• ProxyGen
• OpenEdge Adapter for Sonic ESB
• OpenEdge Adapter for SonicMQ
• Sonic Workbench 7.5.1
• SonicMQ
• Sonic ESB

5
Sonic OpenEdge Adapter for Sonic ESB
Packaged Application
PartnerSystem
Enterprise Service Bus
ESBAdapter
OpenEdge AppServer
6
Why Sonic ESB OpenEdge Application Server

• AppServer Web Service interface is not what you
  want
• Transformation
• Need to route message to different services based
  on context
• CBR
• Combination of the above
• Multi-step business process
• Advanced Web Services standards
• WS-Addressing
• WS-Security

7
Communication Models
Packaged Application
PartnerSystem
WebServices
Rest
Enterprise Service Bus
ESBAdapter
AppServer
8
Web Services
SOAP- based Web Services
Web Services Consumer
Web Services Provider
Sonic
Sonic
Java
Java
WSDL
OpenEdge
OpenEdge
Perl
.NET
Perl
.NET

• An application that can be accessed using SOAP
  over HTTP where the interface is described using
  WSDL
• Standards defined by the W3C

9
REST Representational State Transfer
Rest- based Web Services
REST Consumer
REST Provider

• An application that can be accessed via the HTTP
  GET/POST/PUT/DELETE verbs
• Message content if any typically in the form of
  XML as defined by some XML Schema

10
Designing Interfaces
Public Interface
Packaged Application
PartnerSystem
Public Interface
WebServices
Rest
Private Interface
Enterprise Service Bus
ESBAdapter
AppServer
11
Designing Interfaces
Public Interfaces

• Web Services vs. REST
• Use SOAP when you can leverage tools
• Use REST for simplicity
• Conform to the Industry Recommendations
• Web Services Interoperability Organization
  (ws-i.org)
• SOAP Encoding deprecated use Literal
• Use Document instead of RPC for widest client
  support
• Learn WSDL
• Create WSDL to conform to interface you want
  make it as simple as possible its the contract

12
Designing Interfaces
Private Interfaces

• Interface between Sonic and OpenEdge
• Service is one or more related operations
• Operations should perform a complete unit of work
  make coarse-grained for efficiency
• All OpenEdge services are Request-Reply and can
  return a fault
• RPC/Literal allows mapping of individual
  parameters can use Web Service Invocation
  Editor easier
• Document/Literal allows using transformation of
  entire message

13
Agenda
Developing Business Processes

• Technology Overview
• Developing a Business Process from Start to Finish

14
Company Lookup Business Process
15
Configuring Sonic Workbench with OpenEdge

• Workbench manages two containers for development
• Dev.ESB_Core runs Sonic Services
• Dev.ESB_Test will run OpenEdge Services
• OpenEdge installed container not used for
  development
• Classpath and properties on Test container
  configured for OpenEdge

16
Define the Public Interface

• Defined by an XML Schema
• Use an XML Namespace
• URL if schema can be retrieved at location
• URN if just a name
• Create named types for your interface
• Define Elements for your types
• Many benefits by creating a schema
• Automatic example files
• Eases WSDL creation

17
Defining and Deploying OpenEdge Services with
ProxyGen

• New ESB tab in ProxyGen for 10.1B
• Generates WSM and WSDL files for Sonic
• Deploys them automatically to Sonic Domain
• Defines ESB Service
• Creates Endpoints not underlying Queues
• Optionally deploys service to defined ESB
  container
• Sets AppServer URL

18
Calling OpenEdge Services with a Web Service
Invocation

• Easiest way to call an OpenEdge Service
• SOAP message transient data is what is
  important
• Scenario editor allows live testing of service
• Add invocation to process
• Use mapping tools to extract input parameters
• Many options on handling results
• Scenarios and tracking info help development

19
Using Sonic Transformation Services

• Transformations change results into what you need
• Save results as example document
• Schema says what you want
• Sonic tools ease style-sheet creation

20
Using Sonic Routing Services (CBR)

• Route messages based on content
• Supports message parts or headers
• Routing based on rules files or XPATH
• Rules files written in JavaScript
• No coding required for XPATH
• Routing like a CASE statement
• Can route to first true evaluation or all
• Includes default destination

21
Calling External Web Services

• Same process as calling OpenEdge Services
• Design for unreliability
• Use sub-processes to abstract implementation
• Easier to create new sub-process if Web Service
  goes away
• Create Fault process to be flexible

22
Exposing Business Process to Clients

• Process currently has REST interface
• JMS and ABL clients send messages to Entry
  Endpoint
• HTTP Direct Acceptor for browser-based AJAX
  clients
• Replies specified via JMSReplyTo
• Wrap process to expose as SOAP
• Automatic WSDL generation
• Wrap and unwrap steps

23
Business Process Demo
24
In Summary

• Design, do not generate, your public interface
• Use REST for JMS and AJAX
• Use SOAP for advanced clients (tools,
  WS-Security, etc)
• Follow WS-I recommendations
• Use Document-Literal for widest client support
• Use sub-processes liberally
• Design for unreliability

25
For More Information, go to

• PSDN
• Designing and Deploying SOA Applications on Sonic
  ESB for the OpenEdge Developer
• PSDN Forum
• Education Courses
• OpenEdge Development with Sonic ESB
• Service Oriented Integration with Sonic ESB
• Using JMS in OpenEdge

26
Questions?
27
Thank you foryour time
28
(No Transcript)