INT12: Mastering ProDataSets and Native XML Datatypes with Sonic ESB

1
INT-12 Mastering ProDataSets and Native XML
Datatypes with Sonic ESB
David Cleary
Principal Software Engineer
2
Agenda

• Designing Service Interfaces
• Weakly-typed vs. Strongly-typed
• Using ProDataSets with Sonic ESB
• Using Complex XML with Sonic ESB

3
Products Used

• OpenEdge 10.1B01
• OpenEdge Architect
• ProxyGen
• OpenEdge Adapter for Sonic ESB
• OpenEdge Adapter for SonicMQ
• Sonic Workbench 7.5
• SonicMQ
• Sonic ESB

4
Problem Overview

• OpenEdge Adapter for Sonic ESB doesnt support
  ProDataSets
• OpenEdge Adapter for Sonic ESB doesnt support
  native XML
• ltanyTypegt XML Schema type
• Serialized XML ! Character data
• lttaggt ? lttaggt
• CBR and transformation services wont directly
  work

5
How it is being solved

• Use LONGCHARs at client and server
• Serialize ProDataSets or X-Documents to LONGCHAR
• Specify XML Schema string datatype in interface
  (WSDL)
• ABL Client and server see XML
• Sonic services see character data
• Write Javascript to double parse data
• Extract string data, parse string data

6
There is a Better Way!
7
Designing Interfaces
Public Interface
Packaged Application
PartnerSystem
Public Interface
WebServices
Rest
Private Interface
Enterprise Service Bus
ESBAdapter
AppServer
8
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

9
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

10
Weakly-typed Service Interfaces

• Exact data type not specified in interface
• Single interface supports multiple
  object/entity/data types
• Uses XML Schema anyType
• Validation done by application
• Schema embedded in ProDataSet XML representation
• External schema validation done by namespace
• AutoEdge example of weakly-typed interface

11
Strongly-typed Service Interfaces

• Explicitly defined by XML Schema
• Interface supports single object/entity/data
  types
• Validation should be part of infrastructure

12
The OERA Service Interface
13
The OERA Service Interface

• Dynamic service interface
• Single interface handles all available services
• Weakly typed
• ProDataSets represent Business Entities and
  Service Context
• Schema travels with data
• NAMESPACE-URI attribute can be used for identity
• Optionally validate against external schema

14
OERA Service Interface in ABL
/ proSIgateway.p Service interface layer
procedure that runs non-persistent on the
AppServer to feed client requests to server BEs.
/ DEFINE INPUT PARAMETER pcEntityName AS
CHARACTER. DEFINE INPUT PARAMETER pcOpName AS
CHARACTER. DEFINE INPUT-OUTPUT PARAMETER
DATASET-HANDLE phContext. DEFINE INPUT-OUTPUT
PARAMETER DATASET-HANDLE phIODataSet. DEFINE
OUTPUT PARAMETER DATASET-HANDLE phOutputDataSet.
DEFINE OUTPUT PARAMETER pcExcStatus AS
CHARACTER.
15
OERA Service Interface in ABL On ESB
/ proSIgateway.p Service interface layer
procedure that runs non-persistent on the
AppServer to feed client requests to server BEs.
/ DEFINE INPUT PARAMETER pcEntityName AS
CHARACTER. DEFINE INPUT PARAMETER pcOpName AS
CHARACTER. DEFINE INPUT-OUTPUT PARAMETER
phContext AS LONGCHAR. DEFINE INPUT-OUTPUT
PARAMETER phIODataSet AS LONGCHAR. DEFINE OUTPUT
PARAMETER phOutputDataSet AS LONGCHAR. DEFINE
OUTPUT PARAMETER pcExcStatus AS CHARACTER.
16
Instantiating ProDataSet from XML

• Use the READ-XML method on DATASET HANDLE
• Can validate with internal schema
• Use NAMESPACE-URI attribute to identify
• Use READ-XMLSCHEMA to do strict validation

17
Example of ProDataSet Instantiation
DEFINE VARIABLE dsHdl AS HANDLE. sts
dsHdlRead-XML("LONGCHAR", / source-type /
phContext, / source of XML
/ "EMPTY", / read-mode
/ ?, /
schema-location / FALSE,
/ override mapping/ ?,
/ field mapping /
?). / verify-schema-mode/
18
Serializing ProDataSet to XML

• Use the WRITE-XML method on DATASET HANDLE
• Write schema with Dataset
• Can specify minimum schema for non-ABL clients
• Use NAMESPACE-URI attribute to identify
• Default UTF-8 encoding preferable
• Manually remove XML declaration if inserting in
  XML document

19
Example of ProDataSet Serialization
sts dsHdlWrite-XML("LONGCHAR", / target-type
/ phContext, / target
for XML / FALSE, /
formatted XML / ?,
/ encoding(UTF-8) / ?,
/ schema-location /
TRUE, / write-schema /
FALSE). / min-schema /
20
Service Interface Demo
21
Creating the Public Interface

• Interface created by an ESB Process
• Interface is strongly typed (mostly)
• Entity and operation are constants
• ProDataSets are XML Schema anyType not string
• Can be messaging-based
• ABL clients use OpenEdge Adapter for SonicMQ
• Can be SOAP-based

22
Messaging-based Interfaces

• Easier to model
• Uses multipart messages
• Direct support for TempTable and ProDataSets in
  ABL
• Provides reliability
• Provides true asynchronicity
• Good for long running processes
• Client interface can be abstracted

23
Message-based Demo
24
SOAP-based Interface

• Harder to model
• Really need to work with a single message part
• Less reliable (unless you use WS-RM)
• Synchronous
• Long running processes can timeout
• Use document/literal SOAP
• Widest client support
• Takes advantage of Sonic features
• Wrap message-based process to support both

25
SOAP-based Demo
26
Creating Strongly-Typed Service Interfaces

• Everything defined explicitly in XML Schema
• No anyType allowed
• XML Namespaces are important
• Required for identity
• Allows versioning of objects

27
ABL Classes on Sonic ESB

• Not supported by WSA or ESB Adapter
• Binary representation opaque on bus
• Serialization as XML an excellent solution
• Take full advantage of ESB services
• Easy cross platform/language support (Java and
  .Net)

28
XML Serialization of ABL Classes

• Create XML Schema representation of class
• Use named types
• Define elements of those types

29
Example of Customer Record Schema
ltxsschema targetNamespace"urnCustomerRecord060
7gt ltxselement name"Customer"
type"tnsCustomerType/gt ltxscomplexType
name"CustomerType"gt ltxssequencegt
ltxselement name"CustNum" type"xsunsignedInt"/gt
ltxselement name"Name"gt
ltxselement
name"Orders"gt ltxscomplexTypegt
ltxssequencegt ltxselement name"Order"
type"tnsOrderType" minOccurs"0"
maxOccurs"unbounded"/gt lt/xssequencegt
lt/xscomplexTypegt
30
Serializing ABL Class to XML

• Use SAX-WRITER and LONGCHAR
• Controlled outside of classes
• Classes implement standardized interface
• Calls same interface on embedded classes
• Ensure you conform to schema

31
Example of Serializing Class
METHOD PUBLIC VOID WriteXML(INPUT saxWriter AS
HANDLE) saxWriterSTART-ELEMENT("Customer",
xmlNS). IF pCustNum ltgt ? THEN DO
saxWriterSTART-ELEMENT("CustNum",
xmlNS). saxWriterWRITE-CHARACTERS
(STRING(myCustomer.CustNum)).
saxWriterEND-ELEMENT("CustNum", xmlNS).
IF myCustomer.Name ltgt ? THEN DO
saxWriterSTART-ELEMENT("Name", xmlNS).
saxWriterWRITE-CHARACTERS(myCustomer.Name).
saxWriterEND-ELEMENT("Name", xmlNS).
END. . .
32
Example of Serializing Class
. . saxWriterSTART-ELEMENT("Orders", xmlNS).
FOR EACH myCustOrders CAST (orders,
order)WriteXML(saxWriter). END.
saxWriterEND-ELEMENT("Orders",
xmlNS). END. saxWriterEND-ELEMENT("Customer",
xmlNS).
33
Instantiating Classes from XML

• Use X-DOCUMENT DOM model
• Completely parse and validate data before class
  instantiation
• Walk the DOM tree
• Element node represents class
• All element children represent class data or
  embedded classes

34
Example of Instantiating a Class
METHOD PUBLIC VOID ReadXML(INPUT xNode AS
HANDLE) / xNode points at Customer
element / REPEAT i 1 TO xNodeNUM-CHILDREN
ok xNodeGET-CHILD(xNodeChild, i). IF
NOT OK THEN LEAVE. cType
xNodeChildSUBTYPE NO-ERROR. IF cType
"ELEMENT" THEN DO nodeName
xNodeChildLOCAL-NAME. ok
xNodeChildGET-CHILD(xNodeText, 1).
nodeValue xNodeTextNODE-VALUE. IF
nodeName "CustNum" THEN / set CustNum
value / ELSE IF nodeName "Name" THEN

35
Example of Instantiating a Class
IF nodeName Orders THEN DO REPEAT j 1 TO
xNodeChildNUM-CHILDREN ok
xNodeChildGET-CHILD(xNodeClass, j). IF NOT
OK THEN LEAVE. cType
xNodeClassSUBTYPE NO-ERROR. IF cType
"ELEMENT" THEN DO nodeName
xNodeClassLOCAL-NAME. IF nodeName
Order" THEN DO myOrder NEW Order().
myOrderReadXML(xNodeClass). END.
END. END. END.
36
In Summary

• Design your public and private interfaces
• Strongly vs. Weakly typed
• SOAP vs. REST
• Use XML Namespaces
• Never specify string datatype for XML in public
  interface

37
ABL Class Demo
38
For More Information, go to

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

39
Relevant Exchange Sessions

• INT-12 Mastering ProDataSets and Native XML
  Datatypes with Sonic ESB
• SONIC-1 Whats New in Sonic 7.5
• INT-3 Realistic Service Oriented Architecture
  Approaches
• INT-7 Middleware Roadmap and Info Exchange

40
Questions?
41
Thank you foryour time
42
(No Transcript)