For any Application Integration architecture solution to be successful, there are some key features which perform all the heavy lifting. Following are the key features of Adeptia’s Application Integration ESB solution.
Adeptia Integration Architecture
Adeptia supports all transport protocols enabling applications to transmit messages and connect with other applications or systems. File transfer protocols such as SFTP, FTP, and FTPS are supported along with messaging protocols such as SOAP, REST, AMQP and JMS. Adeptia also connects with on-premise relational databases such as Oracle, SQL Server, MySQL and cloud-based NoSQL databases such as MongoDB and Cassandra. Additional application support includes certified adapters for SAP, JD Edwards, Oracle EBS, QuickBooks, Sage, Shopify, BigCommerce and many more.
Adeptia’s application integration solution has an in-built Events capability that allows developers to configure how and when to kick-off an ESB orchestration. By adding trigger rules, an orchestration can be executed on-demand by a client’s API call or when files are placed in a folder or when a new email with a particular file attachment arrives in an inbox. The type of triggers include API, FTP (including SFTP, FTPS), AS2, Spazio MFT, Email, HTTPS, MQ, AMQP, LAN and through custom event plugins. Triggers also support the use of webhooks that can be embedded in the source applications such as Salesforce or other cloud apps and these webhooks can trigger an orchestration whenever an event occurs in these applications such as the creation of a new record or an update of an existing record.
User can design a service orchestration that dynamically overrides the logical endpoints related to source or target IP addresses or file locations based on specific rules. For example, based on the type of source data or message request, the subsequent call to a particular web service can be dynamically determined at runtime. Not only the endpoints can be overwritten but also the actual service operations can be determined based on different set of rules that are processed during service execution.
When the systems are not directly connected, a service orchestration in Adeptia can send an incoming message to an intermediary system such as a Message Queue and can persist the data before the message is forwarded to an intended target application. Routing can also include message-based routing rules in the process flow that can route the message to a target application based on the content of the data or the sender of the message.
Failures in transmission are reported to users through email notifications and are also logged in the Monitoring & Tracking Dashboards that are already included in Adeptia. The communication failures also contain the actual error description along with failure codes that are useful for error correction and resubmission.
Ability to retry establishing a connection with an application in case of failure is supported in Adeptia. Users can configure the number of retries and the timeout interval between each retry.
Another key point in application integration is allowing users to configure wildcards related to message or file extraction. User can provide wildcards on the folder path or the type of files that need to be fetched from the source location. User can also specify cron-expressions on when to go and pick up the files and what time the polling event needs to be paused.
Adeptia provides publish/subscribe model for developers to implement, publish and share APIs with other applications or clients. It allows for companies to publish the APIs in Adeptia’s API Gateway and clients can register and explore these APIs through the secure, cloud-based Adeptia Connect iPaaS.
For HL7 data messaging the key protocol that companies use is MLLP. This protocol uses the TCP/IP protocol to transfer the data in continuous stream of bytes. MLLP delimiters are used to recognize the start and the end of the message.
Service orchestration or a process flow in application integration solution can send out an acknowledgment on the correct transmission of message directly to the origination system. Depending upon the type of the sender system, the message can be a REST response message with success status or more detailed response that contains the details on the result of the message translation. Acknowledgments can be both synchronous or asynchronous depending upon the type of service being called as the message arrives from the sender. If the message type is asynchronous then Adeptia can produce a token that would allow the sender to correlate the token with the actual message that is generated and sent later on to the sender. Synchronous messaging would send a response message in real-time back to the sender as part of the request.
Adeptia supports application specific connectors for ERP and CRM systems such as SAP. To learn more, check out Adeptia’s SAP-certified integration connector.
• JD Edwards
• Oracle EBS
• MS Dynamics
Users can also use application connectors and connect with legacy systems such as AS400 or IBM mainframe and exchange data with these systems.
Adeptia ESB provides full support for monitoring and tracking of messages as they arrive and get processed in the application architecture integration solution. The monitoring dashboards show several data points related to real-time events, process executions, transaction status, transaction execution lifecycle, data volume, performance metrics, and resource consumption.
Messaging also includes full support of SOAP and REST web services and we will discuss more this component in the next section.
Visual dashboards for real-time and historical data flow executions are available out of the box. User can select an ESB interface and see the runtime trend of process executions, status of each transaction and drill down further and see the metadata details of each micro-service execution. Dashboards are divided into multiple categories:
An important part of application integration architecture is its ability to provide support for Web Services. Process orchestration can be published as both REST or as a SOAP web service. ESB architecture supports the use of different versions for the same API and the creation of different resource endpaths. Developers can create multiple operations for the API such as “getCustomer”, “getCustomerList”, “updateCustomer”, “createCustomer” and each operation can have different parameters that can be passed in the endpoint or in the header. Adeptia also supports the use of API security token and provides documentation for clients to explore and try out the different operations of the published API and validate the connectivity with the service.
Let us list a couple of key features of the Web Services.
Services can be exposed as SOAP-WSDL and REST-JSON interfaces to external clients. Adeptia provides a full meta-data registry to clients to discover and consume APIs.
Below is a sample services registry interface in Adeptia.
(Adeptia Services Registry Interface)
By using this interface users can access API documentation, view endpoints, download WSDLs, try out REST services and can also subscribe to an API through the Connect platform. To learn more, check out Adeptia API Deployment Architecture.
The ESB services can be exposed as SOAP-XML- and REST-JSON-interfaces along with restrictions in terms of which client or application can access these services.
Security Policy for an API can be configured through the Adeptia platform and the interface also provides a centralized repository to manage the policies as shown below.
(Adeptia API Security Policy - centralized repository and management interface)
For sharing of web services with your clients and partners, Adeptia ESB software provides an easy way for your clients to discover and consume your shared services through its cloud-based Adeptia Connect platform. With Adeptia Connect iPaaS, clients can register, explore your published APIs, and connect with them through an easy self-service platform. Self-service integration capability helps employees integrate independently without IT intervention. Clients can request access to any of your published API, the system would prompt for the parameters needed to create a security token and it also provides access to documentation. Service controls such as the amount of data a client can be pass through an API call are also governed through the interface.
(Adeptia ESB – API runtime dashboard)
Along with complete dashboard and API monitoring interface, your clients have full visualization of the runtime and historical execution trend of the application integration services being consumed through the published APIs.
The user interface for the Adeptia ESB architecture is completely graphical visual design studio and the entire ESB functionality is available through the browser. Adeptia supports Active Directory/ LDAP integration and also supports SSO for your developers and business users to login, collaborate and design ESB solutions.
Each service category in Adeptia ESB, whether it is Data Schemas, Data Transformations, Events or Orchestrations are all managed through a centralized services repository. The Services Repository Management interface allows users to browse through services and allows them to easily manage a service in terms of adding it into a version control, organizing it into a project or a classification, looking at impact analysis, viewing service documentation, reviewing service dependencies with other services, and managing its overall access within your organization.
Data transformation and mapping in Adeptia ESB is a visual interface where users can automatically load data layouts or schemas of customer files and map the data to any target format. A visual Data Mapper allows users to:
Data mapper can handle any number of sources and targets and supports all types of data formats such as XML, JSON, CSV, Excel, Fixed Width, Databases, WSDL, EDI and many other data types. Some of the important functions of Data Mapper interface are:
One of the key advantages of Adeptia’s application integration solution is that it combines both ESB and BPM in a single platform. Your data may get extracted automatically from a source application but it may require a human workflow task for someone in your team or from the client end to review the data and make edits before running it through the process flow. In these situations we allow developers to embed human workflow events in the flow that get executed at runtime and the tasks are assigned to users with specific expiry criteria and escalation rules so that they can view the data in a web form, make changes and resubmit the information back into the data flow for processing.
Process Designer is a graphical interface for developers to design and configure ESB orchestrations. Users can pull up any number of services from the service repository and use these services to connect with any source or target application, perform data transformations, call web services, and integrate the data with any system. Processes can be published as APIs as described in the Web Service section above.
Process flow designer provides these features:
Intelligent routing relates to the ability to determine the type of data or request and calling the applicable service in the Service Layer to process that request. For example, when a getPolicyCoverage request is initiated from a Policy Underwriting System, the orchestration called by that request determines the associated service that needs to be called and routes the request to that service for execution.
There are multiple services in a Service Layer and the ability to determine the applicable backend service to process the request is key part of an ESB framework.
Here’s an ESB infrastructure framework for Insurance.
Business processes such as Claims or Underwriting systems exchange data with the backend systems by calling the appropriate service from the Service Layer. An ESB driven application integration framework allows systems and external clients to interact with the backend systems through Services Layer rather than directly touching the underlying systems. Services Layer provides abstraction to the business processes where the customer-facing systems use business logic to exchange information with the data layer without having the need to learn the application logic of the underlying system.
Adeptia provides full documentation of the Adeptia here.