is there any preferred way how to document WSO2 mediation sequences in Enterprise Integrator? For example, if we design the sequence to be reusable (= can be attached to an API or called from other sequences), we would like to document the inputs and outputs of the sequence. So far we didn't find any built-in mechanism for this, just discovered that XML comments disappear from the sequence source files when edited in Enterprise Integrator Tooling.
We are thinking to place a Script mediator as a first one in the sequence. It would be without actual code, but with comments describing the sequence.
Can you perhaps share how you document the mediation sequences?
Thank you in advance.
We used to use WsoDeveloper Studio to manager integrator related projects. Final result is just car file. Despite integrator "erase" comments in deployed files, they are still available in sources. git helps to remember how project is evolved.
Sequence has special field for description.
It can be modified in design screenshot and source view.
<sequence>
...
<description>Bla-Bla</description>
</sequence>
You don't have to use git to see what is this sequence for.
Related
We are planning to use Saxonica EE (yet to buy) in Spring Boot microservice on Cloud Foundry and we want to store the XSLT compiled version in XML in Redis cache so that when do transformation it would be less time consuming, I have below questions, can you please guide me in right direction.
how can we deploy Saxon EE libs with licence to the cloud, any standard practice need to be followed.
is it possible to get the XSLT compiled code in XML format so that I can store in Redis cache, is this approach make sense (if there is any change in XSLT I will re-compile every time)
Any java programming samples, we use xsl:include heavily in all xsls , if there is any example for the same use-case would be great.
For the commercial questions regarding licensing for cloud deployment, that's out of scope for StackOverflow - please contact Saxonica directly to discuss this.
Saxon-EE can compile a stylesheet to a SEF file which is indeed an XML format, but I've no idea whether storing the compiled stylesheets in Redis makes any sense.
If you have a problem using xsl:include, I suggest you raise it as a separate question. A general request for advice on using a particular feature isn't likely to elicit helpful responses - StackOverflow works best if you have a specific technical question, or a specific technical problem. (If you want general advice, my XSLT reference book has about 4 pages on xsl:include, with examples).
I recommend you to start by getting the basic foundation of clarity in place as described below:
About choosing Redis for storage :
If your going for Redis as storage you normally would have to serialize your (XSLT processed) output into XML or JSON prior to storing it into Redis. This means also that any time you want to access the data in a more human-friendly readable way, you would have to deserialize the Redis string.
Answers on your bulleted questions (in relation to XSLT) :
[1] Cloud deployment: Even if you would like to use cloud solutions you would still need to define on which server you would like to install Java/SDK and Saxon libraries (jar). In terms of details around license for cloud solution, I would refer to the company Saxonica.
[2] Need of compiling: Saxon XSLT is not normally being compiled by user (unless there is a reason for it). I suspect when you say "compiled" in this bullet that you mean the transformation process, using a source XML, XSLT for processing and getting an output XML. - If so, you can set which output format you want (XML/HTML/XHTML). Every time you change something in your source- or XSL file, you would need to run XSLT to see the change in the XML output file.
[3] Need of Java samples: You do not need Java knowledge to build XSL stylesheet files. The Java comes into the picture if you choose to run on Java you would need to setup Java/SDK on the machine that would run Saxon XSLT. After the setup (Java/SDK and XSLT) you can choose between calling XSLT from a terminal or create scripts that would call XSLT (I use bash scripts in Linux).
I recommend that you start using an online XSLT tool meanwhile you solve your Java environment and Saxon XSLT. This way you can build up your XSL files or test any of your existing XSL files in order to adjust them to your needs.
Background:
A certain government-backed wholesaler of broadband services in Australia took feedback from discussion groups about how best to deliver B2B services to retail ISPs. They settled on EbXML.
Problem:
We're a very small shop (comparatively) that doesn't want to spend a lot of time going forward on integration. We're already familiar with integration of paired (inbound and outbound) SOAP services. In the past we've made use of WSDL-based code generation tooling (mostly with RPC/Literal services) where the WSDL has been descriptive and simple enough for the code generation tools to digest.
If at all possible we'd like to avoid having to hand-integrate the services with our business 'stack'. We know that the 'Interface Schemas' have been updated several times; we'd like to (as much as possible) do code and schema generation such that we can model our relationship with the supplier and the outbound/inbound messages as simple "queues" (tables) in an SQL database -- this will be our point of integration.
Starting with the outbound ("sender") SOAP web-service... it publishes a Document/Literal WSDL description of the service that seems to work correctly with various tools (e.g: wsdl2java, SoapUI) to generate the EBXML 'wrapper' messages. This says nothing about the 'payload' messages themselves which (at least for the MSH we've looked at) need to be multipart/related attachments with type of text/xml.
The 'payload' messages are defined in the provided CPA (something like bindings) and Schema (standard-looking XSD) files. The MSH itself doesn't seem to provide any external validation for the payload messages.
Question:
Is the same kind of code generation (as seen with WSDL-described SOAP web services) tooling available for EbXML CPAs/Schemas? (i.e: tools that can consume the CPA and 'payload' interface schemas and spit out java/c++/whatever, and/or something WSDL-like specific to the 'payload' interface messages and/or example messages).
If so, where do I look?
If not, are there any EbXML-specific problems that would prevent it? (I'd rather not get several weeks into a project to develop tools that are impossible to implement 'correctly' given the information at hand).
The MSH is payload agnostic. The payloads are not defined in the CPA, only the service and action names that are used to send the ebXML payloads are. The service and action are transmitted in the ebXML header, which is the first part of the multipart message. The payloads themselves can be xml, binary or a combination. Each payload is another part.
An MSH is responsible for tasks like:
sending (usually asynchronous) acknowledgements for received messages
resending messages if an acknowledgement has not been received within a certain amount of time
ignoring duplicate messages
assuring the order in which messages are delivered is correct
the actual behaviour is all configurable using the CPA, but a compliant MSH would support all this.
This implies that an MSH has to keep an administration of the messages it has sent and received, which is usually done in a database.
I would be surprised if you could find tooling to generate an MSH from a specific CPA. What you can find is software/components that implement a generic MSH and that can be configured with CPAs.
Assuming you don't want to build your own, look for an existing ebMS adapter. Configure it with your CPA(s). Then generate the payloads however you like and pass them to the ebMS adapter.
Google for "ebMS adapter" or "ebMS support".
Alas, it seems there's no specific tooling around the 'payload' messages for EbXML, spefically because EbXML doesn't regulate those messages.
However, the CPA (through canSend and canRecv) elements acts somewhat like a SOAP WSDL, and the XSDs serve the same purpose as with SOAP, so it's not too far off.
There does exist software for turning types defined in XSDs into messages (merging in user-supplied data) at runtime, but per my question there's no obvious tooling for code generation around CPAs and related XSDs.
Furthermore, actually writing software to do this yourself is made more problematic by the dificulty of searching for the meta-grammar for XML Schema (i.e: that grammar which remains of XML Schema once XML tokenization is factored out). Basically, this was difficult because in the XML world, the word "grammar" has an different meaning which polutes search results.
I was able to write a parser for the XML syntax snippets present at the top of each of the MSDN articals on XML Schema (elements listed down the left), which in turn allowed me to generate an LL1 grammar for XML schema which works on the pre-parsed AST of a given XSD.
From there I built a top-down parser from this meta-grammar which:
Follows <xsd:import>s and <xsd:include>s to resolve namespaces into further XSDs.
Recursively resolves message types in order to produce a 'flattened' type for each CPA message.
Generates a packer/unpacker data-structures for the message types which allow generation of code in various languages, as well as serialisation to and parsing from validated 'payload' XML.
There are still various XML Schema restrictions, keys, and other constraints that my code generators don't know about, but support for these can be added in time.
I'll update this answer with links to grammars (and possibly code -- depends on legals) as time permits. I'll leave the question as non-accepted for a while so that if someone miraculously finds a tool which makes much less work of the code generation, I'll accept an answer based on that.
We would like to create a contract first ws with wso2brs based on a certain xsd. The object model of the ws generated by the wso2brs must stay conform to this xsd. The strategy we've tried so far is generating java libraries based on the xsd, and then have the brs reason on the java libraries in the brs-project.
The problem is that the object model of the resulting ws exposed by the brs is no longer conform to that of the original xsd. It seems that something goes wrong in the "translation" xsd->javaobject->xml. The java object generators I've tried so far have been jaxb and wsdl2java.
What do we need to do in order to create a "true" contract first ws with wso2brs?
Best regards,
Georg and Philip
when creating a rules service to be deployed on WSO2 BRS that service should contain three components which are (1.)JAR containing the Java classes of facts and results, (2.)Drools file that defines the rules for the sample use case (.drl) and (3.) a rule service configuration (.rsl). So if you want to follow a contract first approach then that would only be to create the java classes, hense the drools file and service config should be part of the end rules service. So the approach you have tried can be the only way. In case if you are having issues in translation I think its better you use an IDE like Eclipse to do the translation for you http://theopentutorials.com/examples/java/jaxb/generate-java-class-from-xml-schema-in-eclipse-ide/
We have requirement for Contract First Web services for one of my Project.
We have defined the WSDL file so I need to generate Java Artifacts from WSDL with JAX-WS,
So Is there any way so that I can generate the Java Server side form exposing the WSDL.
Thanks,
Ramakrishna Rayudu
Take a look at my post here.
It explains how to generate the Metro-JAX-WS-Stubs (artifacts) from a given WSDL using the wsimport-Tool shipped with your JDK.
Hope this helpes! Have fun!
EDIT:
Sorry I missunderstood your question!
Apache AXIS ships with a function called wsd2java. That could be helpful in your case.
Have a look at this post, giving links to tutorials for different IDEs.
Cheers!
use
xjc -wsdl <wsdlurl> -d <directory>
xjc tool can be found inside C:\Program Files\jaxb
I have a basic asp.net webservice that returns a simple response.
To make it ucore compliant I need to apply an XSLT.
Is there a way to apply an XSLT to my response?
I'm aware the receiver can apply it on their end, but in this scenario I need to apply it on my end.
Thanks!
See Custom Message Formatters.
Ignore ASMX web services. They have very little extensibility and are now considered to be "legacy technology" by Microsoft.
Whether you're talking about legacy ASMX or the current WCF web services, you're talking about controlling the serialized XML on output. Both the ASMX and WCF handlers by default will fire the serialization routines for the underlying objects used in their respective web service methods.
You could do it if you want to work outside the construct of serialized XML. Your method could return a string which is nothing more than the output of your method. You would need to:
Go through the logic of building your resultant object
Serialize the object to XML -- as a string
Run an XSL transformation on the XML to an output stream
Return the output stream's contents from your method
This is an extremely lousy hack, though.
EDIT: per John's reference, focus on solving this through control of the output XML. If you're using legacy ASMX, this is basic XML serialization. If you're using WCF, there are greater formatting options available.