[ Transports ] [ Message builders and formatters ] [ Endpoints ] [ Inbound endpoints ] [Proxy sevices][ REST APIs ] [ Topics ] [ Mediators ] [ Sequences ] [ Tasks ] [ Quality of Service (QoS) component ] [ Registry ] [ Management and configuration GUI ] [ Connectors ] [ Analytics ] [ Message routing ] [ Message filtering ] [ Message transformation ] [ Protocol switching ] [ Service chaining ] [ Store and forward ] [ Maven Multi Module (MMM) project ] [ Composite Application project ] [ Data integration ] [ Application and service hosting ] [ Business Processes ] [Microservices Framework] Integration runtime shipped with WSO2 EI comprises of the following high level components: 
TransportsA transport is responsible for carrying messages that are in a specific format. The Enterprise Integrator supports all the widely used transports including HTTP/s, JMS, VFS and domain-specific transports like FIX. You can easily add a new transport using the Axis2 transport framework and plug it into the Enterprise Integrator. Each transport provides a receiver, which the Enterprise Integrator uses to receive messages, and a sender, which it uses to send messages. The transport receivers and senders are independent of the Enterprise Integrator core. For more information, see Working with Transports. When a message comes into the Enterprise Integrator, the receiving transport selects a message builder based on the message's content type. It uses that builder to process the message's raw payload data and convert it into common XML, which the Enterprise Integrator mediation engine can then read and understand. WSO2 Enterprise Integrator includes message builders for text-based and binary content. Conversely, before a transport sends a message out from the Enterprise Integrator, a message formatter is used to build the outgoing stream from the message back into its original format. As with message builders, the message formatter is selected based on the message's content type. You can implement new message builders andformattersusing the Axis2 framework. For more information, see Working with Message Builders and Formatters. EndpointsAn endpoint defines an external destination for a message. An endpoint can connect to any external service after configuring it with any attributes or semantics needed for communicating with that service. For example, an endpoint could representa URL,a mailbox, a JMS queue, or a TCP socket, along with the settings needed to connect to it. You can specify an endpoint as an address endpoint, WSDL endpoint, a load balancing endpoint and more. An endpoint is defined independently of transports, allowing you to use the same endpoint with multipletransports. When you configure a message mediation sequence or a proxy service to handle the incoming message, you specify which transport to use and the endpoint where the message will be sent. For more information, see Working with Endpoints. Inbound endpointsAn inbound endpoint is a message source that can be configured dynamically. In the Enterprise Integrator, when it comes to the existing Axis2 based transports, only the HTTP transport works in a multi-tenant mode. Inbound endpoints support all transports to work in a multi-tenant mode. For more information, see Working with Inbound Endpoints | Anchor |
|---|
| proxy_services |
|---|
| proxy_services |
|---|
|
Proxy servicesProxy services are virtual services that receive messages and optionally process them before forwarding them to a service at a given endpoint. This approach allows you to perform necessary transformations and introduce additional functionality without changing your existing service. Any available transport can be used to receive and send messages from the proxy services. A proxy service is externally visible and can be accessed usinga URL similar to a normal web service address. For more information, see Working with Proxy Services. REST APIsA REST API in Enterprise Integrator is analogous to a web application deployed in the Enterprise Integrator runtime. Each API is anchored at a user-defined URL context, much like how a web application deployed in a servlet container is anchored at a fixed URL context. An API will only process requests that fall under its URL context. A REST API defines one or more resources, which is a logical component of an API that can be accessed by making a particular type of HTTP call. A REST API resource is used by the WSO2 Enterprise Integrator mediation engine to mediate incoming requests, forward them to a specified endpoint, mediate the responses from the endpoint, and send the responses back to the client that originally requested them. We can create an API resource to process defined HTTP request method/s that are sent to the backend service. The In sequence handles incoming requests and sends them to the back-end service, and the Out sequence handles the responses from the back-end service and sends them back to the requesting client. REST APIs allow you to send messages directly into the Enterprise Integrator using REST. For more information, see Working with APIs. TopicsA topic allows services to receive messages when a specific type of event occurs by subscribing to messages that have been published to a specific topic. For more information, see Working with Topics and Events. Mediators are individual processing units that perform a specific function, such as sending, transforming, or filtering messages. WSO2 Enterprise Integrator includes a comprehensive mediator library that provides functionality for implementing widely used Enterprise Integration Patterns (EIPs). You can also easily write a custom mediator to provide additional functionality using various technologies such as Java, scripting, and Spring. For more information, see Mediators. SequencesA sequence is a set of mediators organized into a logical flow, allowing you to implement pipes and filter patterns. You can add sequences to proxy services and REST APIs. For more information, see Mediation Sequences. TasksA task allows you to run a piece of code triggered by a timer. WSO2 Enterprise Integrator provides a default task implementation, which you can use to inject a message to the Enterprise Integrator at a scheduled interval. You can also write your own custom tasks by implementing a Java interface. For more information, see Working with Scheduled Tasks. Quality of Service (QoS) componentThe Quality of Service (QoS) component implements security. For more information, see Applying Security to a Proxy Service. RegistryA registry is a content store and metadata repository. WSO2 Enterprise Integrator provides a registry with a built-in repository that stores the configuration and configuration metadata that define your messaging architecture. You can also use an external registry/repository for resources such as WSDLs, schemas, scripts, XSLT and XQuery transformations, etc. You can hide or merge one or more remote registries behind a local registry interface, and you can configure the Enterprise Integrator to poll these registries to update its current configurations. For more information, see Working with the Registry in WSO2 Admin Guide. Management and configuration GUIThe Management Console provides a graphical user interface (GUI) that allows you to easily configure the components mentioned above. ConnectorsA connector is a collection of templates that define operations that can be called from the Enterprise Integrator and is used when connecting the Enterprise Integrator to external third party APIs. WSO2 Enterprise Integrator provides a variety of connectors via the WSO2 Connector Store. For information on using a connector in your EI configuration, see the tutorial. AnalyticsMonitoring and analytics are provided by the EI-Analytics runtime component and this can be started as a separate runtime. This component provides an analytics dashboard with a host of statistical graphs, message flow diagramsand diagrams and mediator properties. If required, the analytics can be extended with customizations. For more information, see WSO2 Enterprise Integrator Analytics. For information on using the Analytics Dashboard, see the tutorial.
Message routingWhen there is an incoming message into WSO2 Enterprise Integrator, it is able to determine and route the message to the recipient. Routing can also be done based on some component of the message. This is known as content basedrouting -based routing and is done using the Switch mediator. For information inimplementing in implementing content based routing, see the tutorial.
Message filteringThe WSO2 Enterprise Integrator is able to filter out messages based on the message content using the Filter mediator. This feature allows you to perform complex logic, where you are able to filter out messages and send them in different mediation flows.
When sender and receiver messages do not have the same data format, the WSO2 Enterprise Integrator can be used to translate the messages between the sender and recipient. For information on how the Enterprise Integrator can be used for this, see the Message Translator pattern in the EIP Guide. The PayloadFactory mediator and Data Mapper mediator can be used to implement this. You can manipulate messages by adding and removing content from them, converting them to a completely different message format and even validating messages based on the available validation mechanisms of the message format. For an example of how you can implement message transformation using the Data Mapper mediator, see the tutorial.
Protocol switchingThe WSO2 Enterprise Integrator has the capability to take messages that come in one protocol and then send the message out in a completely different protocol (e.g. HTTP to JMS). The protocol bridging technology in Enterprise Integrator takes the business content of a message that comes in from one protocol and sends this content out in a completely different format and protocol.
Service chainingService chaining is a popular use case in the Enterprise Integrator, where several services are exposed as a single service, aggregated service. Enterprise Integrator is used for the integration and sequential calling of these services so that the expected response can be provided to the client. For information on implementing a simple service chaining scenario, see the tutorial.
Store and forwardStore and forwardmessaging pattern isused in asynchronous messaging. This can be used when integrating with systems that accept message traffic at a given rate and handling failover scenarios. In this pattern, messages are sent to a Message Store where they are temporarily stored before they are delivered to their destination by a Message Processor. The Enterprise Integrator is shipped with a few message store implementations and also allows you to implement a custom message store implementation. For information on implementing a store and forward pattern using the in-memory store of Enterprise Integrator, see the tutorial. For information on implementing guaranteed delivery in Enterprise Integrator, see the example.
Maven Multi Module projectWSO2 Enterprise Integrator tooling creates separate projects and a separate Maven pom.xml file for most deployable artifacts. In Maven-centric development, however, you have a parent project and some child modules, including a separate distribution module that is a child module of the parent project. To achieve this model, you can create a Maven Multi Module project in your workspace, create your artifact projects nested within it, and then create the Composite Application project for the distribution module. Building all deployable artifacts within a Maven Multi Module project allows you to build the deployable artifacts using Continuous Integration (CI) tools.
Composite Application projectTo deploy the artifacts to WSO2 Enterprise Integrator, we must first package the artifact project/s into a Composite Application (C-App) project. A C-App also allows you to easily port your artifacts from one environment to another. For detailed information on C-Apps, see Introduction to Composite Applications in WSO2 Admin Guide.
| Anchor |
|---|
| data_integration |
|---|
| data_integration |
|---|
|
Data integrationData services hosted within the Integration runtime can be easily used for an integration solution. You can expose any type of datasource as a data service, which will simply decouple the datasource from its infrastructure and expose the capabilities of the datasource as a service. | Expand |
|---|
| Data services and resources provide a service-and-resource-interface to some data stored in a relational database. In a service interface, you must indicate how service requests map to queries against collections of tables in a relational database and how query results are mapped to service responses. In a resource interface, you must indicate how a set of resources map to queries and how query responses are returned as resource representations (or reports of resource creation or deletion, depending on the HTTP verb in use). The following topics describe the data services configuration language and the key elements used when composing a data service, such as queries, databases, operations etc. along with example syntax. [ Data services and resource language ] [ Configuring the datasource ] [ Defining queries ] [ Defining service operations ] [ Defining resources ] [ Defining event trigger ] [ Security configuration ] [ Sample data service configuration ] Data services and resource languageData services and resources are defined using the Data Services and Resource Language (DSRL) where a <data> element describes a data service or a resource. The common attributes of a <data> element is given in the following example: | Code Block |
|---|
| <data baseURI="xs:anyURI" name="xs:NMTOKEN" enableBatchRequests="xs:BOOLEAN" enableBoxcarring="xs:BOOLEAN" txManagerJNDIName="xs:NMTOKEN" serviceNamespace="xs:anyURI" serviceGroup="xs:NMTOKEN" serviceStatus="active|inactive" transports="http https JMS local" >
config+
query+
operation+
resource+
event-trigger+
</data>
|
| Attribute | Description |
|---|
| baseURI | a REQUIRED URI indicating the base URI for the operations and resources definedwithinthe <data> element. | | name | a REQUIRED name of the data service. | | enableBatchRequest | an OPTIONAL boolean to enable the batch request feature. | | enableBoxcarring | an OPTIONAL boolean to enable the boxcarring feature. | | txManagerJNDIName | an OPTIONAL JNDI name for overriding the standard JNDI location for locating the JTA transaction manager | | serviceNamespace | an OPTIONAL URI to uniquely identify the web service. | | serviceGroup | an OPTIONAL name that is used to categorize data-services in different groups. | | serviceStatus | an OPTIONAL string to enable WIP (specifies weather the data service is deployed or work in progress) support. | | transports | an OPTIONAL string to enable the transports required for the data service. The possible values are "http", "https", "JMS" and "local". |
Configuring thedatasourceThe following sample config gives the common elements used to connect to a datasource: | Code Block |
|---|
| <config id="xs:ID">
<property name="xs:NMTOKEN">xs:urType</property>+
</config>
|
- config/@id: an OPTIONAL XML ID identifying the config element. If the configuration file has multiple <config> elements, then this attribute is required.
The actual set of properties is defined by each type of database connection (e.g., JDBC will have its own standard set). Defining queriesA query consists of parameters that describe how to map the result to an XML element. It is similar to a function that maps some parameters to an XML element. A query definition does not indicate how the parameters are acquired. Instead, it just lists the parameters that are needed, assuming that the parameters will be provided. If the query is at a top level (i.e., direct child of <data>) then either an operation definition or a resource definition provides the context for the parameters. If the query is nested within a <result> element, then the parameter names refer to column names of the result table described in the <result> element of the XML. The following sample config shows the common attributes of a <query> element: | Code Block |
|---|
| <query id="xs:ID"? useConfig="xs:ConfigID" returnGeneratedKeys="xs:BOOLEAN">
<param name="xs:NMTOKEN" sqlType="xs:string" paramType="SCALAR | ARRAY" type="IN | OUT | IN-OUT" ordinal="xs:integer" defaultValue="xs:string" />*
( <validateCustom class= "xs:string"/> | <validateLength minimum="xs:integer" maximum="xs:integer" /> | <validatePattern pattern="xs:string" />)
</param>
( <sql dialect="xs:NMTOKEN">xs:string</sql>+ | <sparql>xs:string</sparql> )
<properties>
<property name="xs:NMTOKEN">xs:string</property>+
</properties>
<result element="xs:QName" rowName="xs:QName" defaultNamespace="xs:anyURI" />
(element | attribute | call-query )*
</result>
</query>
<element name="xs:QName" column="xs:NMTOKEN" requiredRoles="xs:NMTOKEN" export="xs:NMTOKEN" exportType="SCALAR | ARRAY" xsdType="xs:QName">
(element | attribute | call-query )*
</element>
<attribute name="xs:QName" column="xs:NMTOKEN" requiredRoles="xs:NMTOKEN" export="xs:NMTOKEN" exportType="SCALAR | ARRAY" xsdType="xs:QName"/>
<call-query href="xs:NCName" requiredRoles="xs:NMTOKEN" >
<with-param name="xs:string" query-param="xs:string" />*
</call-query>
|
| Attributes | Sub-attributes | Sub-attributes | Description |
|---|
| id |
| |
|
| an OPTIONAL XML ID identifying the query. If <query> is a direct child of <data> then this attribute is required. | | useConfig |
| |
|
| a REQUIRED reference to thedatasourcethat is to be used forquery. | | returnGeneratedKeys |
| |
|
| an OPTIONAL boolean parameter to enable returnGeneratedKeys. Set this attribute to true only in INSERT queries, where the query inserts to a table that has an auto incrementing key column. In such a case, an auto incremented key value is added to the results set. Also see Returning Generated Keys. | | param |
| |
|
| a declaration of a parameter of the query |
|
| a REQUIRED name of the parameter. |
| an
| an OPTIONAL string containing a legal SQL type which defines the type of the parameter. If none is specified then defaults to string. |
| |
| a REQUIRED parameter type. If none is specified then defaults to SCALAR. |
| |
| a REQUIRED only for stored procedures which map the parameter positions with the query. |
| |
| an OPTIONAL default value of the input parameter. |
|
| validateCustom | class | a REQUIRED custom validation class to validate the input parameter. |
|
| validateLength | minimum | a REQUIRED integer when specifying the minimum length of the parameter. |
| |
|
| maximum | a REQUIRED integer when specifying the maximum length of the parameter. |
|
| validatePattern | pattern | a REQUIRED string pattern to validate the string input parameter. | | sql |
| | |
| an OPTIONAL string containingjdbcdriver prefix when need to usesql-dialects. | | sparql |
| |
|
| a REQUIRED string containing thesparqlquery to execute when using RDF asdatasource. | | properties |
| |
|
| an OPTIONAL XML to define advanced query properties. Each property is defined as a child element of this. |
|
| a REQUIRED name of the property. | | result |
| |
|
| a REQUIRED elementdescriibinghow the table resulting from executing the query will be converted to an XML element. If any <column> or <query> child elements are present, then ONLY those are transferred as child elements of the result element (or elements, depending on whether result/@rowName is given or not). The order of the nested <column> or <query> elements defines the order of elements in the result element. |
| |
| a REQUIRED QName which is the name of the element which will hold the results. |
| |
| an OPTIONAL QName which is the name of the element wrapping each row of the result table if more than one element from the table is to be returned. If this attribute is not given, then only the first row is returned and hence no second level wrapper element is needed. |
| |
| an OPTIONAL URI being the default namespace to use for the namespace name of elements and attributesthat result columnsare mapped to. Defaultsto "" (meaning no namespace). |
| |
| an OPTIONAL element (which may occur any number of times) which is used to execute a further query and produce an element which will be present in the parent element as a child. This is used primarily to use a value of a column as key to select data from a new table. |
|
| an OPTIONAL element (which may occur any number of times) indicating how a specific column in the result table is to be mapped into an element |
| |
|
| element/@name | a REQUIRED QName giving the name of the element to put the column data into |
| |
|
| element/@column | an OPTIONAL string giving the name of the column whose value is to be copied into the element. |
| |
|
| element/@requiredRoles | an OPTIONAL string giving the names of roles that who has permission to see the result element. Bydefaultit has set to all users. |
| |
|
| element/@export | an OPTIONAL name giving to the element that to be export outside of query. This feature is used withboxcarringsupport. |
| |
|
| element/@exportType | a REQUIRED parameter when using export option. Used to give the export element type whether scalar or array. |
| |
|
| element/@xsdType | an OPTIONAL indication of the XML Schema type of the element. If none is given defaults to the mapping of the SQL type of the result column named by @column to an XML Schema type as per [SQL XML Mapping] |
attribute |
| an OPTIONAL element (which may occur any number of times) indicating how a specific column in the result table is to be mapped into an attribute of the element representing the current row |
| | | attribute/@name | a REQUIRED QName giving the name of the attribute to put the column data into |
| |
|
| attribute/@column | an OPTIONAL string giving the name of the column whose value is to be copied into the attribute. Either @column or @param is required. |
| |
|
| attribute/@param | an OPTIONAL string giving the name of the param whose value is to be copied into the attribute. Either @column or @param is required. |
| |
|
| attribute/@requiredRoles | an OPTIONAL string giving the names of roles that who has permission to see the result attribute. Bydefaultit has set to all users. |
| |
|
| attribute/@export | an OPTIONAL name giving to the attribute that to be export outside of query. This feature is used withboxcarringsupport. |
| |
|
| attribute/@exportType | a REQUIRED parameter when using export option. Used to give the export element type whether scalar or array. |
| |
|
| attribute/@xsdType | an OPTIONAL indication of the XML Schema type of the attribute. If none is given defaults to the mapping of the SQL type of the result column named by @column to an XML Schema type as per [SQL XML Mapping] |
| |
| an OPTIONAL element (which may occur any number of times) indicating how a specific column in the result table is to be mapped into a query result. |
| |
|
| with-param/@name | a REQUIRED name of the query to put the column data into |
| |
|
| with-param/@query-param | an OPTIONAL string giving the name of the column whose value is to be copied into the element. |
Defining service operationsOperation refers to a Web service operation defined by a query. The operation is defined as an invocation of a query indicating how the parameters of the query are computed or derived. The syntax is as follows: | Code Block |
|---|
| <operation name="xs:NCName" disableStreaming="xs:BOOLEAN"/>
<description>"xs:string"</description>
<call-query href="xs:IDREF" />
<with-param name="xs:NMTOKEN" (query-param="xs:NMTOKEN" | column="xs:NMTOKEN | param="xs:NMTOKEN")/>
</call-query>
</operation>
|
- operation/@name: is the REQUIRED name of the operation.
- operation/@disableStreaming: an OPTIONAL boolean that used to disable streaming. By default streaming are enable.
- operation/@description: an OPTIONAL string used to describe operation.
- operation/call-query: describes how a query is to be invoked with the data received in the operation invocation.
- call-query/@href: an OPTIONAL reference to the query that is to be invoked. If this is missing then a query must be nested within this element.
- call-query/with-param: a description of a parameter binding for the query invocation: says how a named parameter's value is computed.
- with-param/@name: a REQUIRED NMTOKEN identifying the parameter whose value is being specified.
- with-param/@query-param: an OPTIONAL attribute indicating the name of the URI query parameter (from operation/@path) whose value is the value of this parameter.
- with-param/@column: an OPTIONAL attribute naming a column of the immediate parent <result> element. That is, this applies onlyfornested queries and serves the purpose of being able to use a query result as input to a nested query.
- with-param/@param: an OPTIONAL attribute naming a <param> of the parent <query>. That is, this applies onlyfornested queries and serves the purpose of being able to use a parameter of the parent query input to a nested query.
- call-query/query: an OPTIONAL <query> being the anonymous query to be invoked as the implementation of this operation with the parameters identified above.
Defining resources| Code Block |
|---|
| <resource path="uri-template" method="GET|POST|PUT|DELETE" disableStreaming="xs:BOOLEAN">
<description>"xs:string"</description>
<call-query href="xs:IDREF" />
<with-param name="xs:NMTOKEN" />
query?
</call-query>
</resource>
|
This defines the resource identified by "new URI (/data/@baseURI, /data/resource/@path)" and indicates how the request is mapped to a query invocation. Defining event trigger| Code Block |
|---|
| <event-trigger id=xs:NCName" language="XPath">
<expression>xs:string</expression>
<target-topic>xs:string</target-topic>
<subscriptions>
<subscription>xs:string</subscription>
</subscriptions>
</event-trigger>
|
- event-triger/@id: REQUIRED id used to identify the event-trigger, used in data services queries.
- event-triger/language REQUIRED currently only XPath issupported asthe event trigger language.
- target-topic REQUIRED topic, to which the event notifications will be published.
- subscriptions REQUIRED can be any WS-Eventing complient endpoint. For example, an SMTP transport can be used to send a message to a mail inbox, where an email address is given as the subscription. Here many subscriptions can be defined for the given topic.
Security configurationWhen a data service receives messages, it expects to receive a signed and encrypted message as specified by the security policy stored in the registry of your server. Therefore, as shown below, you can embed the security configurations directly in the .dbs file of the data service by adding the path to the relevant security policy. Please see Apache Rampart and Axis2 documentation on the format of the policy file stored in the registry. You can also use the 'enableSec' element to ensure that Apache Rampart is engaged for the data service. | Code Block |
|---|
<policy key="<sec_policy_path>"/>
<enableSec/> |
Sample data service configurationGiven below is a sample data service configuration with queries, resources etc. for your reference: | Code Block |
|---|
| <data name="DSSample" enableBatchRequests="false" enableBoxcarring="true" serviceStatus="active" baseURI="http://ws.wso2.org/dataservice/samples/ds_sample" transports="http https JMS local">
<config id="default">
<property name="org.wso2.ws.dataservice.driver">org.h2.Driver</property>
<property name="org.wso2.ws.dataservice.protocol">jdbc:h2:file:./samples/database/DATA_SERV_SAMP</property>
<property name="org.wso2.ws.dataservice.user">wso2ds</property>
<property name="org.wso2.ws.dataservice.password">wso2ds</property>
<property name="org.wso2.ws.dataservice.minpoolsize">1</property>
<property name="org.wso2.ws.dataservice.maxpoolsize">10</property>
<property name="org.wso2.ws.dataservice.validation_query"></property>
</config>
<query id="employeesByNumberSQL" useConfig="default">
<sql>select * from Employees where employeeNumber = ?</sql>
<result element="employees" rowName="employee">
<element name="last-name" column="lastName" />
<element name="first-name" column="firstName" />
<element name="email" column="email" />
<element name="salary" column="salary" />
</result>
<param name="employeeNumber" paramType="SCALAR" sqlType="INTEGER" type="IN" ordinal="1" >
<validateLength minimum="3" maximum="20" />
</param>
</query>
<query id="updateProductQuantityQuery" useConfig="default" input-event-trigger="product_stock_low_trigger">
<sql>update Products set quantityInStock=? where productCode=?</sql>
<param name="productCode" paramType="SCALAR" sqlType="STRING" type="IN" ordinal="2" />
<param name="quantityInStock" paramType="SCALAR" sqlType="DOUBLE" type="IN" ordinal="1" />
</query>
<query id="createProductQuery" useConfig="default">
<sql>insert into Products (productCode, productName, productLine, quantityInStock, buyPrice) values (?,?,?,?,?)</sql>
<param name="productCode" paramType="SCALAR" sqlType="STRING" type="IN" ordinal="1" />
<param name="productName" paramType="SCALAR" sqlType="STRING" type="IN" ordinal="2" />
<param name="productLine" paramType="SCALAR" sqlType="STRING" type="IN" ordinal="3" />
<param name="quantityInStock" paramType="SCALAR" sqlType="INTEGER" type="IN" ordinal="4" />
<param name="buyPrice" paramType="SCALAR" sqlType="DOUBLE" type="IN" ordinal="5" />
</query>
<operation name="employeesByNumber">
<call-query href="employeesByNumberSQL" >
<with-param name="employeeNumber" query-param="employeeNumber" />
</call-query>
</operation>
<event-trigger id="product_stock_low_trigger" language="XPath">
<expression>/updateProductQuantityQuery/quantityInStock<10</expression>
<target-topic>product_stock_low_topic</target-topic>
<subscriptions>
<subscription>mailto:test@test.com</subscription>
</subscriptions>
</event-trigger>
<resource path="product/{productCode}/{productName}/{productLine}/{quantityInStock}/{buyPrice}" method="POST">
<call-query href="createProductQuery" >
<with-param name="productCode" query-param="productCode" />
<with-param name="productName" query-param="productName" />
<with-param name="productLine" query-param="productLine" />
<with-param name="quantityInStock" query-param="quantityInStock" />
<with-param name="buyPrice" query-param="buyPrice" />
</call-query>
</resource>
<policy key="conf:repository/components/org.wso2.carbon.security.mgt/policy/scenario1"/>
<enableSec/>
</data>
|
|
Application and service hostingWeb applications such as JAX-RS, JAX-WS as well as Jaggery applications can be hosted in EI and used in your integration solution. That is, back-end services and applications that are required for an integration scenario can be easily hosted within the Integration runtime, eliminating the need to use a separate application server. Business ProcessesWSO2 Enterprise Integrator has the capability to run short running stateless business processes as well as
| Anchor |
|---|
| business_process |
|---|
| business_process |
|---|
|
Business ProcessesWSO2 Enterprise Integrator has the capability to run short running stateless business processes as well as long running stateful business processes. However, for long running stateful business processes. However, for long running stateful business processes, you need to use the EI-Business-Process runtime that is shipped with the Enterprise Integrator. Business processes can be written using Web Services Business Process Execution Language (WS-BPEL) and Business Process Model and Notation (BPMN) standards. It also has the capability for human task integration. For a description of the concepts and terminology on business process management, click on the Business Process Management tab.
Microservices FrameworkWSO2 MSF4J (Microservices Framework for Java) is a separate profile that is shipped with WSO2 Enterprise Integrator. This allows developers to quickly get started with developing and running Java microservices. You simply need to annotate your service and deploy it using a single line of code. For more information on MSF4j services, see the following: For more information on WSO2 MSF4J in GitHub, see the full documentation. |