Oracle OpenWorld 2010 Practical Insights on Using AIA (presentation only)

Editor's Notes

• #5: Talking Points AIA 11g offers many new features This may be overwhelming for those who are new to AIA Resulting in less than optimal implementations Share best practices learned from customer experiences in implementing AIA Would like you to think about how you can incorporate these in your implementation Maximize the benefits you gain from the framework I would like to cover three topics today: 1. Reuse & Extend Services  if you are not reusing services, you may as well not be using SOA! Would like to explain how AIA supports reuse using an extensible architecture 2. Build New Services  How to use a holistic approach to service development using AIA’s methodology, productivity and governance tools 3. Planning Integration Rollout  talk about customer experiences when rolling out integration solutions since its more than simply writing SOA code
• #6: Talking Points QUESTION : How many of you are familiar with AIA? To get everyone on same page about AIA… Set of standards based integration products based on Oracle FMW to integrate heterogeneous applications that orchestrate business processes FP = framework containing library of pre-built SOA components that helps in development of loosely coupled process based integrations Foundation Pack pre-built components include: standardized common object model (abstract web services & message payloads - engineered to right level of granularity) e.g. Invoice reference process models that can be used as blueprint to jumpstart your SOA implementation reference architecture , prescriptive programming model ( methodology ) and productivity/governance tools PIP = Pre-built packaged integration accelerators between 2 or more Oracle/non-Oracle apps based on FP common object model DI = Pre-built packaged integration accelerators between 2 Oracle apps w/ only FMW technologies e.g. ODI/BPEL - no common object model This session will focus on an implementation based on a PIP using the common object model Key Message Oracle Application Integration Architecture is a set of integration products that enable companies to create data or process-based integrations across their various applications, reducing the risk and cost often associated with cross-application integrations. With AIA customers can rapidly implement prebuilt integration accelerators or custom build their own integrations leveraging a non-proprietary, standards-based solution designed for optimal reusability, configurability and extensibility. Application Integration Architecture intends to include the required components to orchestrate cross-application business processes, in an architecture designed for adaptability: Foundation Pack 11gR1: Pre-built SOA solution enabling customers and partners to build their own process integrations utilizing AIA’s standardized common object models, methodology, reference architecture, and productivity tools. Foundation Pack provides a detailed methodology and proven design patterns to help guide customers through the most complex integration challenges. In addition, it delivers pre-packaged reference process models and an enterprise library of common objects and services along with extended lifecycle tooling. Process Integration Packs v2.5 (PIPs) : Pre-built, packaged integration accelerators between two or more Oracle/non-Oracle applications, based on the common objects/services provided by Foundation Pack. Direct Integrations v2.5 (DIs): Pre-built integration accelerators between two Oracle applications using FMW Technologies such as Oracle Data Integrator or BPEL Process Manager. (No commons objects/ abstraction layer).   Best in class SOA Suite provides the necessary underlying tools to implement AIA products. In many ways, Application Integration Architecture is Oracle’s own implementation of SOA, and we are extending the value of our experiences to our customers.
• #7: Talking Points The PIP we are going to use is the Communications Agent Assisted Billing Care PIP (currently in 2.5/10g) [Official name] Siebel CRM Integration Pack for Oracle Communications Billing and Revenue Management: Agent Assisted Billing Care What this does is to pull customers Service Usage charge information from Billing system (BRM) and display them in the Siebel CRM UI It allows CSR to resolve customer queries from within one application (Siebel) thereby increasing productivity and reducing costs
• #8: Talking Points Let’s say that company X is implementing this PIP (or similar in-house/partner developed integration) and has following new requirements not in OOTB PIP: Due to introduction of limited data plans, call centers face unprecedented call volumes from customers who want details on data plan charges Show additional data plan usage charges from BRM i.e. BYTES_IN, BYTES_OUT, RUM_NAME – RateableUsageMetric - not available OOTB Allow users to use an existing self service web channel to query this data plan usage Introduce a dedicated BRM instance for US subscribers to improve scalability and performance
• #9: Oracle SOA Suite 10 g : SOA Essentials 1 - Talking Points We will use AIA 11g Development Lifecycle to implement this – which will be shown as chevron on top right as we go along with Tools we use Side Note: these best practices are not just tied to 11g – in fact you can use this with 10g as well, but 11g tools make these a lot more productive and hence shown Here are the recommended implementation tasks that you can incorporate in your development methodology (most customers/partners have one) Let’s go over each task in detail … Task Details (general, not associated with this slide) Identify Integration Flows Functionally drill down to the integration flow Register artifacts and flows in the repository Refine Canonical Model, Services and Applications Extend EBOs or create new EBOs using the methodology Choose what you want to Service Enable vs Re-design for SOA Refine application interfaces to be durable, backward compatible, version enabled, coarse-grained, transactional etc. Map Applications to Canonical Model Ensure service interoperability with the attribute mappings Extend PIP Connector Services Extend using ABCS extension hooks Generate New AIA Connector Services Use Artifact Generator for new Test, Validate, Build, Deploy as per AIA Best Practices Follow best practices; perform black box, white box and automated tests Service Enable vs Re-design for SOA Example: Which one is the right service to create? SalesOrderEBS.createFulfillmentOrder OR FulfillmentOrderEBS.createFulfillmentOrder There is no right or wrong answer – it depends on the domain you would like to add to your SOA ecosystem. If your domain is the Sales system, use the first one; if it includes a Fulfillment system, use the latter. It will influence what EBOs you would need to create and what/how services need to be written. Using FP EOL based EBOs make this easy – the EBOs that are available should be used whenever the object needs to be tracked for any updates. Refine Application Interfaces Durable - Not just created for a given integration or release Backward compatible - For at least one release even if deprecating it Versioning enabled - For inbound interactions Right level of granularity - Not too fine grained, nor too coarse grained Transaction enabled; uses Adapter services if needed - Should honor transaction commit boundaries Conforms to XSD standards; provides WSDL interfaces - E.g. Collection types for CRUD Lists of entities
• #10: Let’s look at how we can extend the OOTB PIP
• #11: Talking Points To reuse, you need to have good understanding of the services and hence it is important to review the service design Start by identifying integration flows being implemented – typically found in requirements/design docs, for OOTB PIP this can be found in Oracle BPA Suite Here we will focus on the Service Usage Event Details flow SLIDE Service Usage (Unbilled Usage) Integration is composed of the following Scenarios: Query Service Usage – fetches the unbilled usage details for a bill profile Query Service Usage Event Details – Gets the CDR/Event details for specific unbilled Item Query Invoice Resource Balance – displays the non-monetary items associated with an event Search Service Usage Events – Search for the events based on date and amount The services used by a customer and captured by the billing system, but not been rated and billed are called Service Usage or Un-billed usage events Service usage, unlike the Invoice details are constantly changing, and the billing system has the most current status of all unbilled usage events The Service Usage process integration retrieves unbilled events from the Billing system to the CRM in real time On click of the Unbilled tab on the Billing Profile Portal screen, the integration process triggers a request to retrieve item charges from the Billing system The integration process also aggregates the item charge information at the service level and displays it as Service Charges This integration additionally enables the CSR to retrieve detailed unbilled data at the item level with a option to specific a search criteria
• #12: Talking Points Review integration design e.g. ServiceUsageEBS abstract web service, operation, payload and concrete implementations for CRM & BRM Note other names for the flow e.g. Usage Allocation /Charge Distribution as this will be useful in identifying message payload attributes [Build] We then identify the sub-projects for the requirements: Extend common object model (EBO) to hold additional fields Extend the connector services (ABCS) to map additional fields Perform configuration changes to add new BRM instance Build new connector service (ABCS) for self service application
• #13: Talking Points Its very useful to document integration artifacts so that we can do a detailed design; pre-built (or even SOA) doesn’t preclude good design Use existing design docs e.g. sequence diagram to identify Message Exchange Patterns e.g. sync, async transaction milestones etc Enumerate integration artifacts in your new implementation doc: Abstract Services/Operations (EBS), Imported Schemas (EBO), Message Payloads (EBM) Concrete Web Services (ABCS) Don’t forget XREF and DVMs – they are critical for service interoperability Once you do this, a lot of the hard work is over! SLIDE Query Service Usage Charge Distribution (CDREvent Details) When you initiate the QueryServiceUsageAllocation process, the following events occur: 1. In Siebel CRM, navigate to the Accounts screen, query an account, and click the Billing Profile tab. This opens the Billing Profile screen. Click the Unbilled Usage tab to open the Unbilled Usage screen. 2. Clicking the Net Amount link for a particular item charge, invokes the CMUUnbilledDetails web service, which in turn calls the UnbilledUsage ABC Interface Service UnbilledUsageSiebelCommsReqABCS with operation QueryEventDetails. UnbilledUsageSiebelCommsReqABCS is a generic Siebel Unbilled Usage interface service with several operations defined. 3. Invoking UnbilledUsageSiebelCommsReqABCS with operation QueryEventDetails routs the Siebel QueryEventDetailsReqMsg to the Siebel ABC implementation service QueryUnbilledUsageEventDetailsSiebelCommsReqABCSImpl. 4. The QueryUnbilledUsageEventDetailsSiebelCommsReqABCSImpl transforms the QueryEventDetailsReqMsg into QueryServiceUsageListEBM and calls the CommunicationsServiceUsageEBSV2 with operation QueryServiceUsageList. CommunicationsServiceUsageEBSV2 is an EBS with several operations defined on ServiceUsage EBO. 5. Invoking CommunicationsServiceUsageEBSV2 with operation QueryServiceUsageList routes the QueryServiceUsageListReqMsg to the appropriate billing systems. OOTB, QueryServiceUsageListReqMsg is routed to the BRM ABC implementation service QueryServiceUsageListBRMCommsProvABCSImpl. 6. QueryServiceUsageListBRMCommsProvABCSImpl looks the value of QueryCode and transforms QueryServiceUsageListReqMsg into the input of PCM_OP_BILL_GET_ITEM_EVENT_CHARGE_DISCOUNT and calls the web service PCM_OP_BILL_GET_ITEM_EVENT_CHARGE_DISCOUNT. 7. API PCM_OP_BILL_GET_ITEM_EVENT_CHARGE_DISCOUNT returns the Item Charge Details output to the calling BRM ABCS Implementation service. 8. QueryServiceUsageListBRMCommsProvABCSImpl then transforms the BRM API output into QueryServiceUsageListRespMsg and returns it to the calling CommunicationsServiceUsageEBSV2 service. 9. CommunicationsServiceUsageEBSV2 then returns the QueryServiceUsageListRespMsg back to QueryUnbilledUsageEventDetailsSiebelCommsReqABCSImpl. 10. QueryUnbilledUsageEventDetailsSiebelCommsReqABCSImpl transforms the QueryServiceUsageListRespMsg into QueryEventDetailsRespMsg, which is returned back to the Siebel Unbilled Usage ABC interface service. 11. UnbilledUsageSiebelCommsReqABCS returns the QueryEventDetailsRespMsg back to the calling Siebel web service CMUUnbilledDetails as CMUUnbilledDetailsResponseMessage. 12. CMUUnbilledDetailsResponseMessage is written to the Siebel Unbilled Item Charge Details VBC for the user.
• #14: Talking Points First sub-project is extending ServiceUsageEBO message payload with three new attributes under ServiceUsageEBO/ServiceUsageLine/UsageAllocation Every EBO has an extension area for attribute addition i.e. “custom” element under each XML node where we need to add these attributes You don’t actually add attributes directly to EBO XSD, instead you add it to custom extension schema that will survive upgrades (sandbox area) Identify extension schema by namespace; in this case its part of common component so it is under ../Custom/Common/… We add three attributes to CustomUsageChargeDistributionType node - remember ServiceUsage is also known as ChargeDistribution Once added, ServiceUsageEBO and all associated EBMs automatically inherit new attributes at the right location. That’s all there is to extending EBOs. BENEFIT : provided you have a good design and follow AIA extensibility standards, all extensions are upgrade safe. Demo script: Open the AIAComponents project in Jdev Open the EnterpriseObjectLibrary/Industry/Communications/EBO/ServiceUsage/V2/ServiceUsageEBO.xsd file. In the schema tree view, drill into the ServiceUsageEBO/ServiceUsageLine/UsageAllocation element and point out the Custom element that we will extend. Open the EnterpriseObjectLibrary/Industry/Communications/Custom/Common/V2/CustomCommonComponents.xsd file. May want to discuss how to determine what is the source xsd to modify after the particular Custom element to be extended has been identified. In source code view, find the CustomUsageChargeDistributionType complex type and uncomment the extension code. Save the file Back in the tree view of the ServiceUsageEBO.xsd file, point out the new fields that appear under the Custom element.
• #15: Talking Points We added new payload attributes, but need to populate them; this is done in BRM connector service mapping stylesheet from response ABM to common object EBM Similar to EBOs, XSL stylesheets also have sandbox area for mapping extensions – i.e. “call-template to <type>_ext” element Similar to EBOs, you don’t actually modify base stylesheet, but another stylesheet with a _Custom suffix that is auto imported We add mappings to UsageAllocationType_ext template which will then be imported into the master stylesheet at runtime BENEFIT : provided you have a good design and follow AIA extensibility standards, all extensions are upgrade safe. Demo: Start Jdeveloper In the QueryServiceUsageBRMCommsProvABCSImpl project, open the PCM_OP_BILL_GET_ITEM_EVENT_CHARGE_DISCOUNT_outputFlist_To_QueryServiceUsageListResponseEBM_Custom.xsl file. In source code view, find the UsageAllocationType_ext template and uncomment the extension code.
• #16: Talking Points Sometimes you enrich attributes values by retrieving them from external systems – this is another commonly used extension capability We saw message & transformation extensions; AIA pre-packaged connector services also have call out hooks that can have any kind of enrich/validate logic Implement desired logic in extension services using provided abstract service WSDLs, register it with AIA and activate call outs by setting configuration properties BENEFIT : Extension services are upgrade safe and provide additional ways to extend pre-packaged capabilities Implementation Steps: (taken from hidden detail slide) Identify the extension point(s) to be made active for the ABCS Implement & deploy extension service using abstract WSDL Copy extension service wsdl w/bindings to AIAComponents Configuration properties (AIAConfigurationProperties.xml) activate the extension points Demo: Open Jdev – NOTE: only using Jdev to look at artifacts.. Don’t need it since we don’t modify the ABCS code Open the QueryServiceUsageBRMCommsProvABCSImpl project again Show the QueryServiceUsageBRMCommsProvABCSImplExtensionAbstract.wsdl file. Explain that this is the interface of the extension callouts. Will need to take this wsdl and implement our extension service according to this interface. In the AIAComponents project, show under the ExtensionServiceLibrary/BRM directory is where you would add your concrete extension service wsdl after you’ve implemented it, replacing the dummy OOTB concrete wsdl. Back in the ABCS project, show the AIAServiceConfigurationProperties.xml file. Explain the extension point properties and the need to set the appropriate property to true to enable the callout. At runtime, the callout will use the concrete wsdl for your implemented extension service. Also explain that at runtime, these config properties are stored in AIAHOME/config
• #17: Talking Points To ensure service reuse by future consumers, it is important to ensure the new attributes are mapped consistently across all projects – in attributes, XREF & DVM XMAN provides aggregated spreadsheet mapping reports across all connector services to help analyze mapping discrepancies in functional design stage, not QA [Build] Use pivot tables to see service attributes usage (common object model on rows and app usage on columns) & do this for all new mappings (extension or new services) If attribute used by one service and not other, then it is potential interoperability issue as that data would not be visible in that app e.g. non-UsageAllocation attributes BENEFIT : AIA provides design time governance tools to ensure service interoperability earlier in the lifecycle QUESTION : How many have used this tool? I would encourage you to check it out – it is even available for AIA 2.x
• #18: Talking Points Adding new instances usually has functional impact to the integration flow To add a new BRM instance for US customers, reuse the connector service since AIA design supports multiple instances for same application However, there are other technical changes to artifacts, especially if you use Adapters to connect to Apps (as BRM does) – see list above Adding Additional Application Instances to a PIP   AIA PIPs out-of-the-box are generally comprised of integration flows that integrate one source application and one target application. Sometimes there are more complex integration flows that may integrate a third or even fourth application as well, but even in these scenarios, the out-of-the-box integration usually assumes that there is only a single instance of each of the applications. The purpose of this article is to describe in general the steps for adding an additional application instance to an AIA PIP. Adding additional application instances to a PIP usually has some functional impact on the integration flows. Therefore, a fully complete and detailed guide must be specific to the PIP in question. This article will cover the general technical steps that must be taken, and so may or may not be fully applicable to every PIP and integration flow. Prior to reading this article, it is recommended to become familiar with the Migrating AIA Instances – Best Practices document (MetaLink note 959705.1), which describes a strategy for moving AIA code plus custom integration code from development to other environments such as QA and Production. This article will refer to the three stages described in that document: Development, Build, and Deploy.   Overview The very first step when considering adding a new instance of an application to an integration flow is to perform a complete functional analysis of the integration flow as it is currently implemented to ensure that it can support the additional application instance. Once you’ve verified that the integration flow can functionally support it, you’ll need to identify all the artifacts that must be created or updated so that the instance can participate in the integration flow. In general, the following artifacts should be considered: Datasources Adapter Connection Factories BSR Systems Entries DVMs XREFs Adapter Services Endpoint Configuration Properties Routing Rules   For each of these artifacts, not only must you code and/or configure the artifact first in your development environment, but you also must provide deployment scripts for the artifact.   Datasources If your new application instance relies on adapters for communicating with the PIP, then it likely will require setting up one or more new datasources and connection pools in OC4J. Datasources and connection pools are maintained in OC4J in the $ORACLE_HOME/j2ee/<oc4j_soa>/config/data-sources.xml file. They can also be added and modified using the Oracle EM console. When setting up a new datasource and associated connection pool for a new application instance, keep in mind whether or not the datasource must support global (XA) transactions. Also be sure to give it a unique jndi name that distinguishes the new application instance’s datasource from any existing new application instances’ datasources. During the development stage in your dev environment, you may wish to add the new datasource(s) using the EM console. However, in order to eventually deploy the datasource to a target server during the deployment stage, you’ll also need to provide ant scripts to perform this deployment. Your PIP probably already includes scripts for deploying the datasource(s) for one application instance. You can find these scripts under the $ORACLE_HOME/PIPS/Core/Setup/<PIPName>/Install directory. There is no strict naming standard for these scripts, but ConfigDataSources.xml is a common name used for the datasource deployment scripts. The out-of-the-box scripts can be modified to include the deployment any additional datasources and connection pools that are needed for the additional application instance you are adding. When modifying the datasource deployment ant scripts, pay special attention to any properties that are referenced which should be considered specific to a particular instance of an application. For example, ${ebiz.db.host}, ${ebiz.db.port}, or ${ebiz.db.sid}, to name just a few. Any code you add for deploying datasources for the additional instance should refer to a unique set of these instance specific properties. The values for these properties usually come from either the $AIA_HOME/config/deploy.properties file or a PIP-specific properties file which is usually located under the $AIA_HOME/PIPS/Core/Setup/<PIPName>/Config directory. Create and add the new set of instance-specific properties to one of these files so that at runtime, your new script code can resolve the references. If you need to encrypt a password before adding it to one of these properties files, there is a script available to perform the encryption. It can be found at $AIA_HOME/Infrastructure/install/install/wlscripts/config/encrypt.sh   Adapter Connection Factories If your new application instance relies on adapters for communicating with the PIP, then it also requires the relevant adapter to be configured with one or more connection factories for the application instance. Adapter connection factories are stored in the $ORACLE_HOME/j2ee/<oc4j_soa>/application-deployments/default/<adapter>/oc4j-ra.xml. The general steps for establishing adapter connection factories for a new application instance are the same as those for datasources. In your development environment you may configure the adapter with a new connection factory using the EM console. Similar to datasources, when you create a connection factory, keep in mind any global (XA) transaction requirements as well as jndi name uniqueness. You will also need to update the relevant deployment scripts so that the connection factory can be deployed to a target server during the deployment stage. Deployment scripts can be found under the $AIA_HOME/PIPS/Core/Setup/<PIPName>/Install directory for the PIP. And once again, there is no universal naming standard applicable to all PIPs by which you could identify the exact script files. One common name used for the script relevant file is, appropriately, ConnectionFactory.xml. At deployment runtime, this ant script file may in turn execute an XSL transformation, which is a separate .xsl file, to insert the required xml into the appropriate oc4j-ra.xml file on the deployment target server. You’ll need to look into the script files for your PIP and follow the execution logic in order to verify exactly which files must be updated with your new application instance’s adapter connection factory. As you do modify the ant and/or xsl script files, be sure not to reference any existing instance-specific ant properties that are intended for an instance other than the one you are adding.   BSR System Entries Each application instance participating in the AIA integration must have a corresponding record in the BSR_SYSTEMS table in the AIA schema. You can add the record for your new application instance using the AIA console. When assigning a System ID to the new record, follow the naming standard described in the Integration Developers Guide. For example, E-Business Suite instances would be assigned System IDs EBIZ_01, EBIZ_02… etc.. It is important to be aware that the System ID assigned here to each application instance will be referenced elsewhere throughout the integration in various artifacts such as XREFs, DVMs, Endpoint configuration properties, and possibly routing rules. As with other artifacts, BSR System entries are deployed via the PIP’s ant scripts in the $AIA_HOME/PIPS/Core/Setup/<PIPName>/Install directory. The script file that performs this deployment is commonly named BSREntry.xml, though it may be named differently. Look for the appropriate script file for your PIP and modify it appropriately to perform the additional database insert for the new application instance. Once again, be sure to refer to the proper set of instance-specific ant properties.   DVMs DVMs are used to maintain code value mappings between the various application instances participating in an AIA integration. DVM data consists of rows and columns stored in XML form. Each DVM typically has a column named COMMON and additional columns one for every application instance participating in the AIA integration. The column name for each application instance must match the System ID for that instance as registered in BSR. During the development stage, DVMs can be modified using the ESB console. Here you can add new rows and columns or modify any of the code values. Since we are adding a new application instance to the integration, you will need to add a new column to all the DVMs in the integration. The new column name must match the System ID for the application instance in the BSR Systems table (eg. EBIZ_02). When adding a new column for a second instance of a particular application to each DVM, you will probably want to seed the new column’s data with the same values as in the column representing the first instance of the application. In order to deploy the updated DVM during the deployment stage, you will need to modify the DVMs’ source XML files with the new column. These source files can all be found under the $AIA_HOME/PIPS/Core/SeedData/DVM directory. Since these are XML files and since they adhere to a known schema, you can attempt to modify all the DVM files programmatically via XSL scripts rather than by hand coding. Creating the XSL scripts to do this are beyond the scope of this document. Some PIPs, such as the Customer MDM and Product MDM PIPs use certain special DVMs in which application instances are not represented as columns in the DVM but rather as row data. Some examples of this kind of DVM are the TARGET_ID and SOURCE_ID DVMs. If your PIP uses any DVMs like this, you would also need to update these DVM XML files, inserting a new row of data to represent the new application instance.     XREFs XREFs are used to store entity ID mappings across all the application instances that participate in the AIA integration. Unlike DVMs, XREFs are usually not seeded with any data at installation time, but rather become populated with data over time as transactions are processed through the integration. However, the XREF definitions must still be updated during the development phase to add the additional column to hold mapped Identifiers for the new application instance. XREF definitions are established on a target server during deployment via the processing of text script files that can found under the $AIA_HOME/PIPS/Core/SeedData/XREF directory. These files must be modified to add the additional column definition for your new application instance. The new column name must match the application instance’s System ID from BSR.   Adapter Services If your PIP integrates applications that require adapters to communicate with or expose web services, then the PIP already includes adapter services for communicating with the application. Each adapter service is implemented in ESB and is configured to communicate with a particular application instance. In order to support an additional application instance, you will need to duplicate each adapter service and configure it to communicate with the new application instance. Use the PIP’s implementation guide to identify all of the Inbound and Outbound adapter services that the PIP uses. The JDeveloper project code for these services can be found under the $AIA_HOME/PIPS/Core/<application> directory structure. Adapter services are usually found in one of the following subdirectories: InboundAdapterServices, OutboundAdapterServices, or JMSAdapterServices. After duplicating the JDeveloper projects and renaming all the necessary files, names, and artifacts in the projects so that the services they define are unique from the originals, you’ll also need to find and replace all instances of jndi names in the projects that are pointing to the adapter connection factories specific to the original application instance. These will need to be replaced with the proper jndi names for the new application instance. These jndi references are usually found in the adapter service’s wsdl file(s) as well as any deployment-related XML files that may be included the project. These deployment-related files are sometimes, but not always, named DeploymentPlan.xml and subscription_build.xml. You should also look for any references in the project to the BSR System ID of the original application instance, and if any are found, replace them with the proper ID for the new instance. Since you are creating new adapters services, you will need to update the PIP’s deployment scripts so that the new adapter services are deployed with the original adapter services during the deployment phase. The PIP’s deployment scripts can be found under the $AIA_HOME/PIPS/Core/Setup/<PIPName>/Install directory. Find the appropriate script files that are deploying the original adapter services and modify them to include deployment of the new adapter services.   Endpoint Configuration Properties Application Business Connector Services (ABCS) are designed and constructed so that a single ABCS can support multiple instances of an application. At runtime, an ABCS must derive the endpoint location for the specific application instance to which it should bind. The mapping between application instance System IDs and their respective endpoints is found in the ABCS’s service-specific configuration properties in the $AIA_HOME/config/AIAConfigurationProperties.xml file. To add a new application instance to the integration, every ABCS that must potentially communicate with the new instance must have its configuration properties updated to include the appropriate service endpoint details for the instance. For an ABCS that communicates with an application via SOAP web service, the endpoint information consists of a soap endpoint address/url. For an ABCS that communicates with an application by way of an adapter service, the endpoint information would consist of the specific adapter service details. For every ABCS in your PIP, you will need to look at the configuration properties and appropriately update or add to them the information to allow the ABCS to bind with the new application instance at runtime. Every service’s project directory contains an AIAServiceConfigurationProperties.xml file that holds these configuration properties particular to that service. During deployment, these properties will be merged into the main AIAConfigurationProperties.xml file on the deployment target server. This merging will be handled automatically by the PIP’s deployment scripts.   EBS Routing Rules The out-of-the-box Enterprise Business Service (EBS) routing rules for a PIP may or may not contain hardcoded application instance identifiers in their routing filter xpath expressions. It is a good idea to look into these routing rules for the PIP’s EBSs to correct any hardcoded application instance System ID references. Even if there are no System ID references, you will most likely need to redefine all routing rules to take into consideration the potential for routing to the new application instance. This is mostly a functional exercise that will be very specific to the PIP and integration flow in question. After having evaluated the existing EBS routing rules and identifying the required changes to support an additional target application instance, you should open the EBS’s project in JDeveloper and edit the routing rules. The source projects can be found under the $AIA_HOME/PIPS/Core/Setup/<PIPName>/EBS directory. During the deployment phase, the out-of-the-box deployment scripts for the PIP will handle the deployment of the EBS with its routing rules to the target server.  
• #19: Talking Points Note that if application instance is not the same app but another third party app, you will need new connector services and mediator routing rules This is similar to building new connector for self service app, which brings us to the topic of building new connectors, but before that… Notes An EBS can be extended in the following ways: Existing operation’s routing rules can be modified to route to alternate provider ABCSs If it is lacking an operation that is required, a new operation can be created If the new operation requires a new EBM, then a new EBM can be created based upon the EBO’s business components and common components Otherwise the new operation can leverage existing EBMs Similarly, a brand new EBS based upon a brand new EBO could always be created Demo: Open Jdev Open the CommunicationsServiceUsageEBSV2 EBS project Open the .esb file and then the EBS service’s routing rules Add new routing rule, pick whatever target service is available Show where to specify filter and transformation.
• #20: Oracle SOA Suite 10 g : SOA Essentials 1 - Talking Points Let’s summarize–Reuse and Extend pre-built services by utilizing AIA’s upgrade safe extensibility framework
• #21: Let’s look at how we build new connector services
• #22: Talking Points New for 11g, although in 10g this was Integration Scenarios in BSR To create new connector, we prefer you not start with Jdev, rather start with registering functional definition – Project, Business Task and SSC (intent) This may look like extra work initially, but it has many benefits: BENEFIT : Tactically, it has immediate benefit of generating SOA composite and project deployment plans BENEFIT : Strategically, the metadata ties functional service definition to implementation giving a holistic view of your SOA implementation BENEFIT : Finally, from a governance stand point it gives org visibility into the intended service weeks or months before it is completed
• #23: Talking Points New for 11g, although in 10g this was AIA Artifact Generator We then use Service Constructor Jdev plug-in to select the SSC and enter implementation details which generates the service draft (or boilerplate) Automates mundane tasks e.g. namespace definitions, EBM header population, extension hooks and message exchange patterns BENEFIT : Reduces manual errors and improves productivity Demo: (applicable to 10g only) Create a new connector for the Self Service app to invoke the ServiceUsage.EBS (Not in Jdev) Open the AIAServiceGenerator/input/Requestor_SyncReqResp_SSQueryServiceUsageDetail.xml file in notepad and show the inputs we are using for the new requester ABCS Open command a window at the AIAServiceGenerator directory and execute ‘ant’ The generated ABCS will be in the output directory Open the project in Jdeveloper. It is already added to the workspace. Talk about the steps required to complete the ABCS: Code the XSL transformations Add any special validation or business logic
• #24: Talking Points Check that all functional metadata is generated since this data will be re-harvested at run time; do this before customizing the file so that you can regenerate later
• #25: Talking Points Next, we need to add message payload transformations from Self Service app (ABM) to common message format (EBM) Mapping using Jdev is easy but the key is to know what to map and this is where the designs are useful ( this is where AIA PIP dev team spends most of the time)!
• #26: Talking Points Enterprise app data models are quite complex (unlike demos such as getQuote) – some objects have thousands of attributes, so mapping is usually non-trivial Ensure that object, attribute, XREF and DVM level mappings are consistent with what Siebel has been implemented before (Siebel-BRM); review service design for this Data Model Details Before I explain the features of the PI, i would like to explain the data model that is adopted for the implementation. The billing products and discount is created in billing system. During the synchronization process the products and discount information is transformed into a generic data structure called Enterprise business object or EBO. These are based on the canonical data model that is a composite of application data models. This eliminates the need to map data directly from billing system to the CRM. The product information in the EBO is used to create products in the CRM system. The usage of the EBO or the canonical data model offers immense flexibility, where one of the edge application can be replaced or upgraded without affecting the Integration solution. For example, the products that are created in Oracle BRM has multiple charges associated with them, like monthly charges and one-time charges. But the target Siebel CRM does not support multiple price types for a single product. So each charge on the product is created as a separate product on the CRM in the current integration. The adoption of EBO or the AIA offers this capability to the PI implementation and can be extended for specific application requirements.
• #27: Talking Points XMAN also provides insight into existing Siebel connector mapping details so that you can avoid mapping discrepancy with the new Self Service connector Report showing attribute, XREF and DVM usage within the Siebel connector service that can be used as the basis for new SSA connector service BENEFIT : AIA provides design time governance tools to ensure service interoperability earlier - at functional design phase instead of QA
• #28: Talking Points New for 11g, although in 10g this was importing IntegrationScenarios in BSR Automating deployment plan generation requires SOA composite info linked to functional metadata entered earlier Use the AIA Harvester; at design time to link composite info and at runtime to link concrete binding information BENEFIT : Provides visibility for service reuse in future projects, for example in how enumerating service artifacts for Extending use case
• #29: Talking Points New for 11g, manual Ant scripts in 10g Once all service metadata is harvested, generate project BOM (i.e. WHAT you need to deploy) and deployment plan (i.e. HOW to deploy) Use the AIA Installation Driver to deploy it to a test environment and fine tune the deployment plan as needed TIP : For heavily customized projects, create copy of the OOTB deployment plan and modify it BENEFIT : Improves productivity – this should be interesting for those who use frameworks such as Maven for deployment tasks Notes: What: The High level information of what to deploy is generated from AIA Project Lifecycle Workbench. PLW provides a fully exposed framework for customers to bundle and deploy components. It generates the Bill of materials as an XML file, that contains list of Composites chosen in Lifecycle Application along with additional data about each composite from harvested annotations. It can be quickly generated for custom built contents too. How: is the Deployment plan. It is an Elaborate and reorganized version of BOM. Defines deployment of all dependant artifacts in addition to composites, and has details for Configuration and Deployments of these artifacts. It is also Extensible for custom deployments Now moving to the where question the details are provided by the Target server information is gathered in AIAInstallProperties.xml . Project Lifecycle Workbench supports Fully functional single server installation and deployment. PLW Supports local, remote and clustered installations Ensuring a correct topology which supports the needs of the enterprise is a crucial step in the process. The topology provides us the answers to the Where part of the question. Where will the services be deployed, clustered, single node , HA are few aspects which should be focused on during the process. It is important to identify what goes where as a part of this exercise. (More details on aspects to topology)
• #30: Talking Points To ensure AIA standards compliance, PIP Auditor scans SOA source code for 200+ rules; projects are given a TOGAF compliance rating level It produces comprehensive report of violations; sliced-n-diced in various categories, drilled down to line level in many cases as shown above Apart from code level compliance, solution architecture reviews are strongly recommended, for which we have a validation checklist BENEFITS : Deep level of design time governance; improved productivity and quality QUESTION : How many have used this tool and checklist? I would encourage you to check it out – it is even available for AIA 2.x
• #31: Talking Points Another level of validation is automated regression tests using test harness & simulator; testing the integration component even for unit tests This shows an example of using the AIA CAVS (you can implement this using other technologies such as iTKO Lisa)
• #32: Oracle SOA Suite 10 g : SOA Essentials 1 - Talking Points To summarize–Use AIA’s holistic approach to service development using the methodology and various developer productivity/governance tools
• #33: This phase encompasses all the “GO live” activities, it is important to note that we are no longer talking about the individual service or a single development artifact but talking about the aggregated artifacts in the ecosystem.
• #34: Talking Points Develop new integration flows by Extending or Building New connectors (providers or requestors) and modifying routing rules For a totally new flow, you would create new EBOs, EBMs, EBS, operations, connector services and mediator routing rules You may also use Direct Integrations where the pattern justifies it; and also consider custom and legacy integration processes Notes e.g. Connect to new billing system Need to develop a new ABCS for the Billing System Research on the web services/ APIs available for the new billing system Look at the mandatory input parameters Extend the corresponding EBO/EBMs Determine the mapping between ABM and EBM Style of interaction pattern is defined Follow the AIA developer’s guide Modify the routing rule to point to the new billing system Modify the existing Siebel ABCS if the output of the new billing system is different May need to modify the Siebel schema and UI to display the new output values from the new Billing system
• #35: Talking Points Services need resiliency for production use, so there is still some work to be done to make these services we built production ready Message Handling : Does the message being passed around have sequencing needs? Does Order2 need to be processed before Order1 or Do Orders need to be aggregated before processing? In my ecosystem does Target System consumes and processes messages much slowly than Source System generating it. How do I handle those needs? Guaranteed Message Delivery : We need to ensure none of Business messages are lost. Therefore clear transaction boundaries need to be defined for Guaranteed delivery for messages. To use Message Resubmission, EBM Header needs to be populated with resubmission values Fault Policies and Error Handling : Think about the happy paths and not so happy paths with fault policies and error handling situations, how do I want my error message to be handled, retired , redirected. Are these values set correctly in the fault policies? Security : And its equally important to figure out the security aspects of various services. These topics are discussed in detail in AIA Integration Developer’s Guide. Once all these aspects finalized we could say we are complete with the development of the services.
• #36: Talking Points This would also be the time to test advanced deployments such as in a remote instance or cluster, which is supported by AIA Installer. Installer will automatically detect presence of a SOA Cluster and prompt the user with fields for appropriate additional information. Users can choose to connect to RAC databases New nodes can be added or removed without any additional configurations No need to have AIA Home/configuration files on each node. It is important to understand the physical and logical topologies to help in environment planning, and in configuration and deployment scripts Develop a policy for end to end lifecycle management including builds, installs and patching Define desired production topology upfront (even large customers fail to do this) This can impact not only your environment planning, but the SOA Suite install as well as build/deploy scripts
• #37: Talking Points When planning network topology, consider the logical distribution of services within clusters e.g. by functional domain or by PIP Note that even though functional based clusters can be desirable for load balancing, they cannot be supported for pre-packaged integrations Workload can be distributed effectively to multiple clusters allowing for optimal usage of resources. Such distribution allows for selective scaling, upgrade and maintenance. New resources can be added or removed easily. For example, an Order to Cash Integration may need more resources seasonally This will also depend on the shared services and service inter-operability among various integration flows. In some cases, it is desired for them to share some data such as XREF whereas in some scenarios they should now. All these considerations should be made. This concept applies even to custom and legacy integration processes, not just AIA
• #38: Talking Points Also plan the physical topology of a typical AIA installation – this is no different than normal SOA cluster planning We need to segregate various layers and define appropriate security zones. High availability is ensured at all levels (web tier, application tier and database tier). Application and data tiers are also secured as they lie within firewalls. Because AIA integrates business-critical Enterprise software, it is important to ensure that there is no single point of failure and that system maintenance and failure recovery can happen without impacting the business.
• #39: Talking Points Finally, there are various other considerations when going live that need to be planned so that you can avoid any show stoppers Environments : Ensure all environment are provisioned upfront and they adequately represent the production topology. Ideally all environments should be identical but at least QA environment should be replica of the production. Performance and Scalability Testing : Performance testing is an iterative process and there is no magic bullet for this. Adequate time and resources should be dedicated to ensure that required KPI and SLA are met. Data Migration : should not be left till the end. End User Training : Ensure end-users pilot the new solution Resources : Of course adequate resources are needed at various phases of the development lifecycle (give customer example) In all, for a successful roll out of AIA in your enterprise I would recommend this Mantra, Think Big, Start Small and Adopt Incrementally
• #40: Oracle SOA Suite 10 g : SOA Essentials 1 - Talking Points To summarize–Adequately plan your rollout of the integration solution to ensure success of your AIA / SOA implementation
• #41: Talking Points We have now satisfied the implementation requirement (and customer) using an architecture designed for sustainable extensions Here are the key take aways…
• #42: Talking Points You can contact us at any time for more info [Questions] We have shared best practices from our customer implementations I hope you have found them useful and will incorporate them in your implementation To maximize the benefits from the AIA framework
• #46: Talking Points AIA’s reference architecture is built for upgrade-safe extensibility at each of its architecture layers EBS = Enterprise Business Service = Abstract Web Service Definition EBO/EBM = Enterprise Business Object /Message = Common Message Definition /Payload ABCS = Application Business Connector Service = Concrete Web Service Implementation of EBS for given application
• #47: Talking Points Here you can see the abstract WSDL that needs to be implemented, along with the operations and payloads Implementation Steps: Identify the extension point(s) to be made active for the ABCS Implement & deploy extension service using abstract WSDL Copy extension service wsdl w/bindings to AIAComponents Configuration properties (AIAConfigurationProperties.xml) activate the extension points Demo: Open Jdev – NOTE: only using Jdev to look at artifacts.. Don’t need it since we don’t modify the ABCS code Open the QueryServiceUsageBRMCommsProvABCSImpl project again Show the QueryServiceUsageBRMCommsProvABCSImplExtensionAbstract.wsdl file. Explain that this is the interface of the extension callouts. Will need to take this wsdl and implement our extension service according to this interface. In the AIAComponents project, show under the ExtensionServiceLibrary/BRM directory is where you would add your concrete extension service wsdl after you’ve implemented it, replacing the dummy OOTB concrete wsdl. Back in the ABCS project, show the AIAServiceConfigurationProperties.xml file. Explain the extension point properties and the need to set the appropriate property to true to enable the callout. At runtime, the callout will use the concrete wsdl for your implemented extension service. Also explain that at runtime, these config properties are stored in AIAHOME/config
• #48: Talking Points If application instance needs a different service operation, you need to create a new EBS and develop new connector services Notes Use ServiceOrder as example. Standard operations of Create, Update, Sync, Delete, Query are delivered OOTB for every EBS. If an additional operation is needed for a new integration flow, the EBS can be extended. Eg. ValidateServiceOrder Nothing to demo here.
• #49: Talking Points We now use JDev extension to select the SSC and enter implementation details which generates the service boilerplate Automates mundane tasks e.g. namespace definitions, EBM header population, extension hooks and message exchange patterns BENEFIT : Improves productivity Demo: (applicable to 10g only) Create a new connector for the Self Service app to invoke the ServiceUsage.EBS (Not in Jdev) Open the AIAServiceGenerator/input/Requestor_SyncReqResp_SSQueryServiceUsageDetail.xml file in notepad and show the inputs we are using for the new requester ABCS Open command a window at the AIAServiceGenerator directory and execute ‘ant’ The generated ABCS will be in the output directory Open the project in Jdeveloper. It is already added to the workspace. Talk about the steps required to complete the ABCS: Code the XSL transformations Add any special validation or business logic
• #50: Talking Points Cross Reference usage within connector services also need to be reviewed carefully to ensure service interoperability SLIDE 14 XREF = Cross reference tables XREF tables are used to store application specific Ids and their respective common Ids. These are the List of Cross reference Tables used in AABC PIP
• #51: Talking Points This shows the runtime flow of the AIA Harvester during design time and run time metadata harvesting Notes Design-time  abstract WSDL metadata harvested Release-time  harvesting for deployment / roll out AIAHarvest.sh [–mode [AIA|OER]] –settings <harvestSettings.xml> Post deployment-time  deployed composites in SOA server What is it? A client program that publishes metadata related to the implementation artifacts into the backend server of the AIA Project Lifecycle Workbench Example of the implementation artifacts: Composite project (including composite.xml and etc.) Interfaces (including EBS.wsdl, EBO.xsd, and etc.) Example of metadata Information relating to composite deployment Adapter composite: ConnectionFactory, Queue/Topics, and etc. Relationship among implementation artifacts: Asset graph Command-line utility in 11gR1, and will be a jDev plug-in down the road Why do I need It? Collecting metadata on the implementation artifacts so to enable downstream automation (e.g., auto-generating deployment plans and etc.)
• #52: Talking Points Black box testing is usually a given in any integration testing, but we would also stress automated regression testing i.e. white box testing
• #53: Talking Points PIP Shared Artifact Analyzer (part of Code Auditor) allows you to plan for service co-deployment on a single FMW instance For every PIP combination, it shows shared artifacts between the integrations that may or may not cause issues with routing rules overwriting
• #54: Talking Points We have now satisfied the implementation requirement (and customer) using an architecture designed for sustainable extensions Notes Instead of having to go back to BRM to find products/pricing…. All billing details are now available in CRM and there is no need to ALT+Tab to the BRM screen any more Implementation Requirements Show additional data plan usage from BRM (BYTES_IN, BYTES_OUT, RUM_NAME – Rate Usable Metric) which is not included in pre-packaged flow Display unbilled service usage via self service web channel Introduce another BRM instance for non-US subscribers