Title: INT12: Mastering ProDataSets and Native XML Datatypes with Sonic ESB
1INT-12 Mastering ProDataSets and Native XML
Datatypes with Sonic ESB
David Cleary
Principal Software Engineer
2Agenda
- Designing Service Interfaces
- Weakly-typed vs. Strongly-typed
- Using ProDataSets with Sonic ESB
- Using Complex XML with Sonic ESB
3Products Used
- OpenEdge 10.1B01
- OpenEdge Architect
- ProxyGen
- OpenEdge Adapter for Sonic ESB
- OpenEdge Adapter for SonicMQ
- Sonic Workbench 7.5
- SonicMQ
- Sonic ESB
4Problem 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
5How 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
6There is a Better Way!
7Designing Interfaces
Public Interface
Packaged Application
PartnerSystem
Public Interface
WebServices
Rest
Private Interface
Enterprise Service Bus
ESBAdapter
AppServer
8Designing 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
9Designing 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
10Weakly-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
11Strongly-typed Service Interfaces
- Explicitly defined by XML Schema
- Interface supports single object/entity/data
types - Validation should be part of infrastructure
12The OERA Service Interface
13The 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
14OERA 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.
15OERA 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.
16Instantiating 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
17Example 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/
18Serializing 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
19Example 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 /
20Service Interface Demo
21Creating 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
22Messaging-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
23Message-based Demo
24SOAP-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
25SOAP-based Demo
26Creating Strongly-Typed Service Interfaces
- Everything defined explicitly in XML Schema
- No anyType allowed
- XML Namespaces are important
- Required for identity
- Allows versioning of objects
27ABL 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)
28XML Serialization of ABL Classes
- Create XML Schema representation of class
- Use named types
- Define elements of those types
29Example 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
30Serializing 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
31Example 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. . .
32Example 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).
33Instantiating 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
34Example 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
35Example 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.
36In 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
37ABL Class Demo
38For 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
39Relevant 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
40Questions?
41Thank you foryour time
42(No Transcript)