Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Oracle OSB Tutorial 2

1.
Oracle Service Bus – Lesson 2Name – Rakesh GujjarlapudiEmail Address – rakesh_gujj@yahoo.comScaling Integration Infrastructure with Oracle Service BusOracle Service Bus - End Point Management & Service Result Caching  Multiple endpoints, Oracle Service Bus can guarantee service availability even if one endpoint is offline. This is an infrastructure resiliency proof point.  Load balance service requests across endpoints according to a variety of algorithms. For example, if one service endpoint were more expensive to use, a weighted message dispatching algorithm can be configured to favor the less expensive service, while still guaranteeing message routing to all available endpoints.  Dynamically adjusting message routing across multiple endpoints in the event that one or more are unavailable. OSB automatically checks offline service endpoints for their availability, and adds them back into the active service endpoint pool when they are back online

2.
IntroductionBusiness continues to grow rapidly. Failure of a service causes transactions processing failures.Issues1. The current Credit Service Validation Service Provider cannot handle the load.2. Due to the failures, checking status of the PO orders causing unnecessary load and spikes on infrastructure.OSB will help scale integration infrastructure through Endpoint Management and Service Result Caching.Endpoint Management  Provide additional capacity for increased load of the service requests  Contract to multiple Credit Card Payment Vendors to ensure high quality of service for POProcessing thus insulating customers from any disruptions of services caused by backend Service Providers.Advantage – Since the service is allready virtualized on Oracle Service Bus, we can make updates quickly andeasily without impacting Service Consumers or the backend Application Developers of the POProcessing service(Service Provider).In this lesson we will bring on-line another credit validation vendor leveraging the advanced EndpointManagement features of Oracle Service Bus.Before Endpoint Management – Single Endpoint.After Endpoint Management – Multiple Endpoints add Agility and Scale

3.
Key Takeaway: Changes are made without any impact to Service Consumers or Providers.Oracle Service Bus helps insulate service consumers and service providers from these types of changes, allowingbusiness to be more agile, robust and adaptable. Changes are made without any impact to Service Consumers orProviders.What is being done?During this section you will perform the following steps.You will start by re-configuring the validationForCC Business Service to have multiple endpoints. The BusinessService will now load-balance across the two service providers: the original endpoint and new provider endpointjust added.You will test and Monitor endpoint utilization from the OSB Monitoring console by invoking ValidateCreditproxy service several times from OSB Test console.High Level Steps  Add endpoint http://<IP ADDRESS>:7001/Credit_Services/ProxyServices/ValidateCredit to the validationForCC business service.  Set the load balancing algorithm to round-robin.  Test the ValidateCredit proxy service multiple times to distribute service requests across both service endpoints.  Validate message distribution to multiple endpoints through the OSB Operations console.Steps in detailAdd the New Credit Card Validation Service EndpointLogin to the Service Bus console (http://localhost:7001/sbconsole) username weblogic, password welcome1.Create a session by clicking the Create button in the Change Center.Use the Project Explorer navigate to the BusinessServices folder of the Credit Services project.To access the configuration for business service validationForCC, click on it’s name.

4.
Notice that there is a single service endpoint defined.We are going to add a 2nd service endpoint and we have been provided the service url.http://<IP- ADDRESS>:7001/Credit_Services/ProxyServices/ValidateCredit.To start the process of adding a 2nd service endpoint, click the edit icon in the Transport Configuration headerbar.This screen appears.Copy the new url and put it in the url field next to the Add button.Click the Add button to add the 2nd url to the list of available endpoints. There should now be 2 urls in theendpoint table.Ensure the endpoint load balancing algorithm is set to round-robin.

5.
There are no more configuration actions to take. Click the Last button then scroll to the bottom of the page andclick the Save button.Ensure that proxy service ValidateCredit is configured with Monitoring enabled, with an Aggregation Interval ofat least 25 minutes.Activate SessionActivate the Session by clicking on Activate in Change CenterAdd optional Description and click Submit

6.
TestIn order to test the changes find the ValidateCredit proxy service by navigating to Resource Browserfollowed by Proxy Services. Next, launch the test console by clicking on the icon under Actions.In the test console, replace the CCNumber value with 1234-1234-1234-1234 and click Execute.You should see the following response.Click the Back button and run the test a few more times.

7.
Navigate to Operations.Click on the Service Health tab.Towards the bottom of the page services are listed.Click on the validationForCC business service to view the aggregate service metrics. Take a minute to browse themetrics page and get familiar with the available data.To view metrics per endpoint click on the Endpoint URI’s tab.Notice that the service requests are distributed across the two endpoints.

8.
Service Result CachingLabBProblem: Because of the Service Failure issues, IT keeps repetitively checking Purchase Order status causingunnecessary load and spikes on IT’s infrastructure.Implement the SolutionIT will leverage OSB’s Service Result Cache to normalize the spikes for repetitive service calls. By caching theresults of repetitive service calls, Oracle Service Bus can help scale and protect backend systems, avoidingoutages caused by spikes enabling predictable scalability. The backend service can even temporarily go downyet cached results can still be returned (within a predefined time window) to ensure no loss in availability.What is being done?During this section you will perform the following steps.Configure Service Result Caching on the GetPO Business Service, which retrieves the Purchase Order given theID of the Purchase Order. Enabling Result Caching will cache the Purchase Order in the Coherence CacheTest Service Result Caching functionality by invoking the GetPO Proxy Service, which Routes to the GetPOBusiness Service. First request for a Purchase Order will take 5 seconds, while the following requests (performedbefore the cache entry is expires from the Coherence Cache) will be much faster as the Purchase Order is servedfrom the Coherence cache.High Level Steps  Import starting-caching.jar into OSB  (Optional) Test to see that every request to the GetPO Proxy Service takes about 5 seconds as Service Result caching is not enabled on the GetPO Business Service to which the GetPO Proxy Service Routes. For simplicity, the GetPO Business Service invokes the POStatus/TestServices/POProvider test service on

9.
OSB that waits for 5 seconds before responding with a Purchase Order. In reality, this service can exist any where.  Configure Service Result Caching on GetPO Business Service  Cache Token Expression – $body/po:PO_ID  Expiration Time – 1 minute  Update GetPO Proxy Service to propagate cache-originated and cache-token response metadata (from the GetPO Business Service) as SOAP Headers. cache-originated and cache-token are available in the Proxy Service at $outbound/ctx:transport/ctx:response/tp:cache- originated and $outbound/ctx:transport/ctx:response/tp:cache-token respectively.  Test to see that first request to the GetPO Proxy Service takes about 5 seconds. However, following requests for the same Purchase Order (same PO_ID) if made within 1 minute (Expiration Time) of the first request is much faster than 5 seconds as the Purchase Order is retrieved from the Coherence Cache. The request will take 5 seconds once the cache entry expires.Steps in DetailCreate SessionNavigate to System AdministrationIn Import Resources, Click BrowseSelect starting-caching.jarClick NextClick ImportClick Activate

10.
Click SubmitCreate SessionClick Resource BrowserSelect Business ServicesEdit GetPO Business Service by clicking the service name

11.
Click on the Message Handling Configuration section to edit Result Caching. Note that currently ResultCaching is set to Not Supported.Expand Advanced Settings by clickingCheck Result Caching to Supported to enable rest of the Result Caching configurationSetup Result Caching configuration. The Cache Token Expression evaluates to the cache token part of the cachekey used to cache the entry in Coherence Cache. The Expiration Time evaluates to the Time To Live for the cacheentry.Cache Token Expression: $body/po:PO_IDExpiration Time: 1 min

15.
Click Save AllClick ActivateClick Save AllClick SubmitYou are done withConfiguring the GetPO Business Service for Result Caching andUpdating the GetPO Proxy Service to insert the cache-originated and cache-token response metadata(from the outbound) into the SOAP Headers (on the inbound)TestSelect Project Explorer and expand POStatus/ProxyServicesClick for GetPO Proxy Service to test

16.
Specify PO_ID as 2222 and click ExecuteYou will notice that it will take about 5 seconds to return with the PurchaseOrder response. This is because thePO service, invoked by the GetPO Business Service, is mimicked by POStatus/TestServices/POProvider proxyservice which has a Java callout that waits for 5 seconds before returning with the Purchase Order. You will seethe following response which indicates the response was not retrieved from the cache (cache-originated=false).You will also see the cache-token that was used to add the entry to the Coherence cache (cache-token=2222)

17.
Immediately within 1 minute of the first request make another request with the same, 2222, PO_ID. Click Backand Click Execute to perform this step

18.
You will now see the following response. This response has cache-originated=true, which implies thePurchase Order came from the Coherence Cache. The header also has cache-token=2222, which is thePO_ID.If you repeat the test again after the cache entry expires (more than 1 minute after the first request)you will see the same response as in previous step. The response comes from the backend (instead of the cache)and the response is cached using the specified cache-token.