How can I create an XML document starting from data retrieved from a database using WSO2 techonologies? - wso2

I am absolutly new in WSO2 technology. I am working on a WSO2 Enterprise Integrator project using ESB and Data Service Server to extract some data from database tables.
So what I have to do is to generate a complex XML document starting from the data retrieved from the database by some queries.
So I have to:
Perform some queries using Data Service Server
Then using these retrieved data to build an XML document that use these data for the XML field values, something like this:
<?xml version="1.0" encoding="UTF-8" ?>
<singleField>value related to a record obtained by QUERY 1</singleField>
<multipleField>value related to a record obtained by QUERY 1</multipleField>
<multipleField>value related to a record obtained by QUERY 1</multipleField>
<multipleField>value related to a record obtained by QUERY 1</multipleField>
So for example I will have 2 different simple select query:
QUERY 1: that always will return a single row: the obtained value have to be putted as value of the ... XML field
QUERY 2: that may return multiple record, so for each of the returned record I have to put a new ... element into my XML (using the related record value obtained by the query as value of this XML element).
WSO2 allows me to create an XML document in this way? What is the best tool (in WSO2 techonlogies set) to do it?

You can build a proxy service , that will invoke a soap data service and write it to a file for you
Generate or create the data service via the DSS : (sql -> soap service (DSS))
https://docs.wso2.com/display/DSS310/Developing+Data+Services
Integrate with the Data Service via an ESB Proxy service. (soap service (DSS) -> proxy (ESB) -> file) The output of the file can be done via :
VFS transport (http://wso2.com/library/articles/2011/01/wso2-esb-example-file-processing/)
File connector (https://docs.wso2.com/display/ESBCONNECTORS/Working+with+the+File+Connector+Version+2)

Related

Specifying connection parameter values as registry entries in DB report mediator in WSO2 EI

I am trying to insert data into a database using the DB report mediator in WSO2 EI. Using Integration Studio 8.0.0 for developing the API. Everything works fine on hardcoding the connection parameters inline as shown below.
Now, I want to specify the connection parameters as registry entries. So, created local entries under registry config. But not sure how to set them as parameters in DB report configuration. When I tried as below, it reads the entire content of the registry local entry instead of just the value and fails. Need suggestions on how we can set the connection parameters as registry entries?

How to test multiple Web Services with one script using UFT?

I am trying to create a set of Regression Test scripts to test the different Web Services and the corresponding methods related to my Web Application in HP UFT. I am using the API testing feature of UFT. I have the request and response XMLs (obtained manually) of each web service method necessary for the testing. There are more than 50 web service methods to be tested. The test cases for all of them are same. The input data of the request is currently being set by parameterizing the data from an excel spreadsheet.
Since the test cases are exactly same and the input data for all the web service methods have similar fields, such as First Name, Last Name, LoginID etc., I want to know if there is a way to write a single script which dynamically reads the web service method name and the associated data from the spreadsheet and uses it in the request XML file (same name as the web service method) which is also loaded in run time.
In this way, after the script has been developed, all I need to do prepare a list of all the web service methods to be tested and enter them in the Test spreadsheet along with the required request data. The script would loop through all the web service methods and execute the test cases for each web service method one by one.
in your case I think you should use a Soap Request method rather than a Web Service Call. Using soap request, other than the message itself, you can parameterize also the Endpoint Address and the SoapAction
Hope this helps
Yossi

How to split the message and receive element into WSO2 ESB 4.7.0

Hi i am receiving the file from remote server which in .csv format into wso2 ESB proxy service and i am getting the response as
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><text xmlns="http://ws.apache.org/commons/ns/payload">firstname,lastname
a,John
b,Scott
c,Tiger
d,Manager
</text></soapenv:Body></soapenv:Envelope>
but how can i split this message element by element and receive each element into ESB Proxy service.
Guide me how can i receive the split message into ESB and store into database.
I guess, you can use smooks mediator and convert CSV data to XML. Then data can be retrieved using XPath. There is a Stackoverflow question on this, Please go through it. Also you can use db report mediator to persist data in to preferred database. You find doc from here. One you convert data to XML, then you can use XPath to define the data that must be persisted in to database. However, you can even write a custom medaitor for ESB, if you want to do some more things than that. Here it explains how to write a custom mediator

Request Structure in WSO2 DSS

I m working on WSO2 DSS 3.0.0. I m sending request structure via SOAP UI to DSS. I m not getting the expected output.
I want to check what is the request structure query that is hitting DSS.
In short I want to see what Query DSS is forming at runtime.
Any help would be appreciated.
Thanks and Regards.
The request format depends on the data service opertions you have created. Each of these opertion invokes an query. And these queries have input parameters and output parameters. The opertion name + input parameters will determine the format of the request message and the output parameters determine the result format of the message.
You can use the WSDL of the relevant data service for creating the SOAP UI project. Then the request message for each Data Service opertion will be there. Or you can simple try-it the dataservice using available Try-it[1] option for the service. There also you can see the request format for each operation.
[1]http://docs.wso2.org/wiki/display/DSS300/Testing+WSDLs

Is it possible to have multiple xsd mappings in a webservice?

I'm new to web services and I'm facing a design issue where we want to create a web service (preferably SOAP based) which will receive 2 parameters:
a string variable (Client Name);
XML data.
There are currently 2 different consumers of this web service but their number will increase. All consumers have separate XSD data that they will be sending, for example:
Consumer1:
<ConData>
<Customer>
<FirstName>FirName</FirstName>
<LastName>LasName</LastName>
</Customer>
<Acocunt>
<Number>112971</Number>
</Account>
<Order>
<OrderNum>0092123</OrderNum>
</Order>
<ConData>
Consumer2:
<ConData>
<SysData>
<CustomerFirstName>Name</CustomerFirstName>
<CustomerLastName>Name</CustomerLastName>
<AccountNumber>Au1o2n</AccountNumber>
<OrderNum>koo912</OrderNum>
</SysData>
<ConData>
This web service is supposed to take the XML data from these clients and store it into the database based on the consumer name. There is no processing required on our end for validating the XML as such, we just take it and store it in the database.
As a good design though, I'd like to define my web service with explicit parameters. The problem is that since their XML data format is different I'm not able to use a single XSD schema as a parameter in my WSDL. I can think of 2 options to address this:
1. Let them pass XML data as String in my web service instead of XSD mapping parameter. Though this is a valid approach, it seems like a bad design based on what I've read so far on the forums as it voids validation and needs lots of manual marshaling and unmarshaling and other problems. Plus my WSDL will not be able to define to my clients what format is expected etc.
2. Create 2 separate web services which will handle different individual consumers with their own XSD's. This again seems less viable since in future if we add more consumers we will have to add new web services with duplicate code for the same operation etc.
I was looking to see if there is a way to define multiple XSD's in a single web service WSDL or maybe a better way of solving this problem.
On a side note, I'd prefer to have a SOAP based web service but if this problem gets resolved using a RESTful web service in a better way then I can consider that as well.
You don't need to have a different web service or skeleton for each client, you just need a different WSDL.
Forget about sending this XML parameter as string, it has disadvantages that I won't repeat here since you already read about it too. So you need to send it as XML.
To keep it into one web service, you create the web service so that it accept any XML as input (type <xsd:any> for the parameter). Type <xsd:any> will mean any kind of XML, but at least it would be XML that you can validate for structure, for starters.
This simplifies versioning of your web service as you don't need to change the code when adding another XML type of input but unfortunately you lose strong typing for your web service and the WSDL generated for the web service will not state anything about the structure of the XML it's expecting (any XML is too vague). Your web service skeleton will be created with a type like Object, XmlElement, XmlDocument or whatever in your code. And the same will happen with all your client stubs.
But for your clients this can be fixed from the WSDL by providing each client with a different WSDL.
For that you create a WSDL of your web service with common content for all clients, except the <types> section, and then merge this common WSDL for each client with their own XML Schema. You will then expose each WSDL on different URLs for each client.
Now the clients will be able to generate strong typed stubs based on their own particular WSDL.
When a client makes a call to your web service, you identify the client XML Schema and use it to validate the XML parameter and see if it's the expected content.
And if the above seem to much, then you can always choose a loosely typed RESTful web service. Whatever solution you choose though, just make sure that you validate the incoming XML using the schema of the client that's sending it.