This Post provides some of the Important Industry Best Practices on EAI. Best Practices are building blocks of an EAI.Best Practices will guide for implementing better Integration Solution. They offer practical advice for the EAI practitioner.
Best Practice-1 Build decoupled and distributed Architecture
Plan a head before building any Integration Architecture.Architecture should be decoupled for flexibility purpose as well it’s distributed. Components should be service oriented as well as Event driven.
- Identify Synchronous/Asynchronous Operations
- use Appropriately in the EAI Framework
Best Practice-2 Identify Common Services and Start building
Identify commonly used Services like (Error-Handling, Event Tracking, Central Logging) in the Component oriented Architecture and plan for building these components for sharing across the Enterprise with in the EAI Domain. Business processes will be used these services as central back bone services in the EAI Hub.
Best Practice-3 Plan for Common Objects
Plan for Common Objects as Global Business Objects that can use across Applications in the Integration space for that Applications can communicate easily without enforcing any Application specific objects in the EAI Hub.
Best Practice-4 Create a common vocabulary
Planning requires the creation of common vocabularies (i.e. taxonomy) to ensure proper understanding and consideration of how to manage, change and use taxonomies. A common vocabulary also facilitates the collaboration and sharing of information across different business areas. Further, as an enterprise defines a common vocabulary, the enterprise should also develop related vocabulary governance.
With both, vocabulary mapping between business areas or communities of interest (for example, relating tracks to targets or installations to supply points or units to weapons systems) becomes much more manageable.
Best Practice-5 Design for connections, change, and control
The enterprise should build a topology of services that reflects the business processes, not the systems, thereby giving the enterprise the ability to make changes. Organization leaders should think in terms of how the enterprise business model and EAI will operate in the context of both the business as well as within the IT infrastructure.
Best Practice-6 Build Templates for Business Processes and Human Workflows.
Build Templates a head for Business Processes and Workflows that include proper logging and Error Handling and common services for that developers follow certain standards for developing any business process across Enterprise while Integration
These usage of these templates should be documented in Developer’s GUIDE for detail reference.
Best Practice-7 Build standards for Messaging and Business Processes
Build Standards for Messaging and Business Processes a head and include those in developer’s guide for reference.
Best Practice-8 Plan a head for Testing Integration Applications
Build Standards for Messaging and Business Processes a head and include those in developer’s guide for reference.
Best Practice-8 Plan a head for Testing Integration Applications
Plan a head for Testing Integration Applications in different Environments like Development, Test and Performance.
• Plan to load production data into Test Env.
• Plan for Initial Load
• Plan for loading any cross-reference data that applications are using in the Integration Env.
• Plan for Integration as well as System Tests on Test Env.
Best Practice-9 Build standards for Messaging and Business Processes
Build Standards for Messaging and Business Processes a head and include those in developer’s guide for reference.
Best Practice-10 Building with Deployment in Mind
It is vital to keep the end goal in mind--deployment. In a sense, the EAI isn't real to the rest of the company until a solution is deployed. Yet, often, key deployment issues are ignored in the design and construction phases of the project. Here are four ways to actively address deployment in the solution:
Instrument components for monitoring: Primary system components should be instrumented for monitoring. These include the ability to provide information on the availability of the system as well as other metrics such as CPU utilization, memory utilization or open resource connections. This information is vital for systems administrators to tune the system for optimal performance. It also affords the development team detailed knowledge of how the system performs in a production scenario.
Account for installations and updates. Any deployed solution must account not only for the initial installation but also for ongoing updates to system components. In some deployments, updates to integration rules and components such as adapters may prove to be a regular activity. The ability to install and update without the loss of continuous operations is essential once the system is in production.
Establish service level agreements. Service level agreements (SLAs) should be established and articulated well before deployment. In fact, they should be articulated as part of the requirements process. The SLA defines the system's requirements at run-time with regard to availability, resource consumption and system performance characteristics.
Build a deployment plan upfront. Building a deployment plan before a single line of code is written is a way to ensure that deployment issues surface earlier rather than later. A deployment plan should walk through how each phase of deployment will be enacted. It needs to articulate all the necessary activities required to support deployment and ongoing maintenance of the solution. It should include coverage of installation, documentation, technical training and the timing of the deployment.
Best Practice-11 Plan for incremental transformation and deployment.
EAI is an iterative process requiring incremental transformation and deployment plans. The key point is that Organizations should start with a simple first step, automating the data collection process.
Best Practice-12 Profile Performance Early and Often
Profiling system performance should be a practice conducted at key points throughout the development process. Measuring and analyzing system performance carries two primary benefits.
First, it is far less costly to correct performance issues and bottlenecks early in the development life cycle. This is particularly true if the performance issues are related to a design flaw. Addressing fundamental design issues during or after the initial deployment is very expensive. Second, discovering the root of a performance problem after the entire system has been constructed can be extremely challenging from a technical perspective. You are often limited by the scope of what can be observed, and this in turn is a result of the tracing and auditing facilities built into the system. It can also be influenced by many more variables, such as network traffic. Instead, by testing not only the individual components as they are constructed but also the baseline architecture, you can establish a more granular view of system performance. Discovering and resolving performance limitations early is simply easier and leads to better results at the end of the project.
Best Practice-13 Build a Traceable System
One overlooked aspect of EAI is the challenge of run-time debugging. Detecting problems in distributed integration architectures is extremely tricky and requires that the system be instrumented with tracing code. Tracing code allows you to track the progress of data and the execution of code segments as that data is processed. Often, in an effort to meet the project schedule, the time allotted to building in tracing code is eliminated in preference for functionality. Whether you are constructing your own EAI system from scratch or leveraging a product to implement an EAI solution, you need to ensure that the system is traceable. The reality is that no matter how much testing is conducted in the lab environment, some problems inevitably arise only in production scenarios. The introduction of "live" data coupled with production application usage often results in extending the system in ways that are not possible to duplicate in the test lab. When such problems are discovered at run-time--or sometimes even when production deployment is under way--it becomes difficult to fix them without being able to trace the flow and execution of the EAI solution.
Also bear in mind that levels of tractability need to be defined, since tracing can hurt overall system performance. It helps to set a low tracing option initially as you debug the system.
Best Practice-14 Reviewing and Addressing Secondary Scenarios
Secondary scenarios arise when the flow of data is not completed within the expected course of execution. For Example as shown below:
The process is loading AP/GL Data from PAL to Oracle Financials through EAI Hub.
However, what if the database in Oracle Financials is busy processing other operations and the Load AP/GL data times out? How does the system handle a failed retrieval or a returned error? This is an obvious but common secondary scenario. Another scenario may occur if, in the course of executing the rules in the Integration Process, if Integration server goes down. How does the system deal with an integration flow halted in mid process as a result of failure at one point? The number of secondary scenarios for a given system is seemingly infinite. Practically speaking, it is not possible to address every one of them. However, a regular practice of conducting reviews of possible secondary scenarios--documenting and subsequently addressing them--must be an essential practice. An EAI solution that addresses secondary scenarios will adhere to certain principles of behavior.
• Message preservation. The system should never lose data in the event of a system failure.
• Data integrity. In the event of a system failure, the system should always preserve the integrity of the message.
• Predefined exception handling. Failed operations must have a predefined course of execution.
• Graceful exits. Operations that fail because of unavailable resources or errors should always "exit gracefully" and return to a known state. Failure should never leave the data flow in an undetermined state whereby data is not reliable and the corrective course of action is unknown.
No comments:
Post a Comment