Showing posts with label XML. Show all posts
Showing posts with label XML. Show all posts

Saturday, 30 December 2017

Convert xsd:anyType data into XML Data

Recently I encountered this requirement to Accept AnyType Data and convert it into a valid xml data.

Few important things to consider is: The AnyType data payload should be a valid one with the namespaces defined.The type to be converted to should be declared in an xsd.

In my process I had to get this anyType data and convert it to a format with which I had to invoke a service.
Though it sounds very simple I felt its better to document it in a very easily accessible way. I followed the following steps for the same in SOA 11.1.1.4:

  1. Create 2 variables to which you want to convert the anytype Data to.
  2. Use the following function to Parse the value:oraext:parseXML(bpws:getVariableData('inputVariable','request','/ns2:Request/ns2:Details/ns2:xmlData')) where xmlData is of datatype Any.Please note that when you are selecting the anyType data, in Assign activity this will not get copied in the expression builder, hence you need to manually add this data.
  3. Once this Assign activity is completed, use Assign or Transform activity to transform the values within the xml generated in the above mentioned step to another variable which is used to invoke the service.
I hope this helps for people looking for usage of oraext:parseXML.

Saturday, 2 September 2017

XML Standards for XML-Message based integrations (Oracle SOA).

XML Standards for XML-Message based integrations (Oracle SOA).
Background:
  • Now a days, majority of the enterprise integration solutions (especially that are using SOA design patterns) and packaged ESB applications such as Oracle's SOA/OSB/BPM, SoftwareAG's Webmethod, TIbco's ActiveMetrix, IBM's Websphere, Mule's MuleESB and many more are are extensively using XML based configurations and messages to integrate different kinds of heterogeneous applications.
  • So, standardizing the XML-Model is one of the key-success criteria in designing the SOA based integration solutions.
XML Message/Schema Standards
  • Always define the definition of an xml message in hierarchical pattern.  example: xml structure for an employee in finance department should follow : <department><finance><employee>xxxx</employee></finance></department>, instead <dep_fin_emp>xxx</dep_fin_emp>. 
  • Where ever possible, use elements rather attributes.  There is always a debate whether to use attributes or elements to represent the properties of an object. Using elements (instead attributes) provides more flexibility to extend the properties of that object/element. Here the main point is - element can easily extendable, where as attribute is not. Example: extending <department><name>xx</name><rev>xx</rev><exp>xx</exp></department> causes lesser cost than changing <department name="XX" rev="xxx" exp="XXX"/>.  Reason: Elements are more flexible than attributes, particularly when it comes to writing extensible schemas, as you can always add additional elements to an element. However, once an attribute has defined, it cannot be extended any further.
  • Always follow a specific pattern to name the xml elements and attributes. Meaning, either follow the camelcase or simplecase but not both. Example: use either xxxXXX or xxx_XXX but not both patterns (there is nothing harm in using both, but it looks ugly especially when you expose your service to external world).
  • If you are defining types (complex or simple types) then always post-fix name with "type" for better readability . Example <complexType name="employeeType"> .. </complexType>
  • Always keep Elements and attributes name between 12 char to 15 char length. 
  • Always tend to use real-life objects for Element names.  Example: use employee, party, partner, address, user, status etc for element names., instead prefix with company or product names. example : use <item><type>engineering</type> .. </item> instead <enggItem> .. </enggItem>
  • Always define schema with a target namespace. Namespace is equivalent to a package name in plsql and java programming languages.  This approach provides better readability and clarity on the elements that are using in the messages.
  • Where ever possible, use Qualified element and attribute names in the XML messages.  This approach provides clarity on what namespace an element belongs to, and removes the confusion or ambiguity and provides the context in which an element is defined.
  • Namespace should follow http://org.<<your company name>>.com/<<domainname>>/<<xsd or wsdl>>/<<functional area>>  example: http://org.ppk.com/purchasing/xsd/order
  • Preferably,  try to define element types (complex or simple types) and use it while defining the elements (messages) instead creating the local elements.  Example: use <xsd:schema ...> <complexType name="employeeType"><sequence><firstname type="xxx"/><lastname type="xxx"/></sequence></complexType>  and refer this type in the element <department><employee type="employeeType"/></department>  instead <department><firstname type="xxx"/><lastname type="xxx"/></department>.  This approach provides modularity and reusability in defining the XML Elements and messages.
  • Preferably, try to construct a canonical model based on multiple, reusable and logical schema models.  Example: avoid creating a single schema definition abc.xsd  by "including" sales.xsd, employee.xsd, order.xsd, finance.xsd, though it provides single namespace and easy development. Instead "import" required schemas to create a name space for your particular domain/project (just like importing required packages in a java classes).
  • For Oracle SOA (SOAP) based message integrations, due to the limitations defined by WS-I  , preferably choose document style binding with the combination of Document Wrapped style (with this approach, the request and response parameters for an operation are wrapped within a single request and response element).  This ensures that the SOAP body only contains a single nested element who name matches that of the operation. 
  • Make sure that, all the canonical schemas and common xml types stored/procured in a common repository from where all the SOA projects (Oracle SOA Projects) shares/references these schemas and types appropriately.   In my next blog, I will provide more details on common-repository (MDS) setup and usage.

Monday, 28 November 2016

JSON(JavaScript Object Notation)

JSON is a syntax for storing and exchanging data.
JSON is an easier-to-use alternative to XML.

JSON Syntax Rules:
    Data is in name/value pairs
    Data is separated by commas
    Curly braces hold objects(note: one xml record can be treated as one json object)
    Square brackets hold arrays

observer below examples to understand how to create JSON documents.
ex1(one object with one data field):
xml:
<firstName>john</firstName>
json:
{ "firstName": "john" }


ex2(one object with two data field):
xml:
<firstName>john</firstName>
<lastName>Doe</lastName>
json:
{"firstName":"John", "lastName":"Doe"}


ex3(one object with three data field):
xml:
<firstName>john</firstName>
<lastName>Doe</lastName>
<middleName>xyz</middleName>
json:
{"firstName":"John", "lastName":"Doe", "middleName":"xyz"}


ex4:
xml:
<employee>
    <firstName>john</firstName>
    <lastName>Doe</lastName>
</employee>
json:
{"employee": {"firstName": "john","lastName": "Doe"}}

ex5(One json object with nested array json objects):
xml:
<employees>
    <emp>
        <firstName>john</firstName>
        <lastName>Doe</lastName>
    </emp>
    <emp>
        <firstName>Anna</firstName>
        <lastName>Smith</lastName>
    </emp>
    <emp>
        <firstName>Peter</firstName>
        <lastName>Jones</lastName>
    </emp>
</employees>
json:
{
  "employees": {
                "emp":
                    [
                      {"firstName": "john","lastName": "Doe"},
                      {"firstName": "Anna","lastName": "Smith"},
                      {"firstName": "Peter","lastName": "Jones"}
                     ]
                }
}

ex6(One json object with nested multiple(same and different types) json objects):
xml:
<school>
    <student>
        <sno>101</sno>
        <sName>sai</sName>
    </student>
    <student>
        <sno>101</sno>
        <sName>sai</sName>
    </student>
    <class>
        <std>6</std>
        <section>A</section>
    </class>
</school>
json:
{
  "school": {
             "student": [
                            {"sno": "101","sName": "sai"},
                            {"sno": "101","sName": "sai"}
                        ],
             "class": {"std": "6","section": "A"}
            }
}

online tool:
http://www.utilities-online.info/xmltojson/#.VrxfNFJgm0U
use this tool to validate and understand how json is working.


XML vs JSON:
NOTE: XML and JSON both are the data interchange formats accessed over WEB. Both of these formats have their own pros/cons. No one is replacement of other. Use the right tool for the right job.
1. JSON format is lightweight over XML.
2. JSON can contain integers, strings, lists, arrays. XML is just elements and nodes that need to be parsed into integers and so on before it can be consumed.
3. The most important disadvantage of JSON is that the format is very hard to read for humans, and that, of course,    every single comma, quote, and bracket should be in exactly the correct place. While this is also true of XML, JSON’s welter of complicated-looking syntax, like the }}]} at the end of the data snippet, may frighten the newbies and make for complicated debugging.
4. Serialization format for your data, JSON is smaller, lighterweight and generally faster than XML.
5. JSON is best for consumption of data in web applications from webservices for its size and ease of use, especially due to the built-in support in JavaScript.
6. For configurations file XML is better choice to make because it more human readable.
7. XML is document-oriented. JSON is data-oriented. JSON can be mapped more easily to object-oriented systems.
8. XML and JSON both use Unicode.That help in support for internationalization.
9. JSON does not have afeature, so it is not well suited to act as a carrier of sounds or images or other large binary payloads. JSON is optimized for data.
10. XML documents can contain any imaginable data type – from classical data like text and numbers, or multimedia objects such as sounds, to active formats like Java applets or ActiveX components.
11.JSON is a better data exchange format. XML is a better document exchange format. Use the right tool for the right job.
12. For Data delivery between servers and browsers, JSON is better choice.For storing Information in configuration files on the server side, XML is better choice.
13. Querying data: Using XPath, it’s possible to get direct access to a part of multiple parts of an XML data structure; no such interface exists for JSON. To get data from a JSON structure, you must know exactly where it is or else iterate over everything until you find it.
14. To extract data from database; XML is the only choice.
Imagine the computation overhead for parsing an xml fragment compared to the instant lookup in JSON.
NOTE: post your comments and subscribe to my blog.

Thursday, 19 November 2015

Adding nodes and creating variables in XSL - Oracle SOA 11G

Hi guys,

Today I am gonna write about,how to use summation function in XSL and how to create a cariable and use it in your xsl. Actually,there was a requirement in our project,which was like adding some values of some fields in the input and based upon the sum we required to pass some value to the target system.So, to accomplish this we used sum function, that is available in xslt.

I will be demonstrating it taking one example.Suppose we have some fields that are coming in the input such as A,B,C and we need to add all these values and see whether its sum is greater than zero or less than zero.If the sum is greater than 0, we will pass say "pass" and if its other way around we will pass say "fail" to the target system.I have create a sample BPEL process for this usecase.Process is very simple: it is exposed as webservice and taking input from the client and after doing aforesaid transformation and logic will publish the message in jms Queue.I will just explain the XSL part.


Step1: In my transformation, first I will create a variable that I will be using to storing the sum of all the required nodes. So in your xsl on target node,right click and add variable "tempVar".
Step2: Drag and drop "Sum" function from Mathematical functions in the centre of xsl.
Step3: Now in the function add all the nodes that you want to add separated by "|".In this example I am adding surcharge,tax,vat,shipmentcharge nodes.






 <xsl:variable name="tempVar"
                select="sum((/imp1:employee/imp1:surcharge | (/imp1:employee/imp1:order/imp1:Tax | (/imp1:employee/imp1:order/imp1:VAT | /imp1:employee/imp1:order/imp1:shipmentCharge))))"/>


Step4: Based upon the sum we need to send value in the target XML.So in our case if its greater tha 0, We will send "Invocie" in typecode tag and "Credit MEmo" otherwise.To implement this add a choose when and otherwise condition. 
Step5: It will check the value of "tempVar" and based on the result,value will be set in the target xml.

Step6: Now deploy and test your composite. First we will test for positive vsalue.I have passed values in all the field greater than 0.As per our logic value in Typecode tag is sent as "INVOICE".
Step7: To check the opposite scenario,pass values such that sum is less than 0.Values now passed is "Credit Memo".
In this way we can use the sum function and also you learned ,how to create a variable in xsl and use that in your XSL.







NOTE: There can be scenarios where values in some nodes can be empty.So you have to handle that as well,otherwise,you will get "NaN" in your result.Hence in order to handle blank nodes use below expresssion:

sum((/imp1:employee/imp1:surcharge[. != ""] | (/imp1:employee/imp1:order/imp1:Tax[. != ""] | (/imp1:employee/imp1:order/imp1:VAT[. != ""] | /imp1:employee/imp1:order/imp1:shipmentCharge[. != ""]))))
  
Hope this post is useful to you guys.

Happy Learning,
Cheers !!!