Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« December 2010 | Main | February 2011 »

January 31, 2011

Starting a SOA Project? Don't forget the Service Registry!!

In the SOA world, there are several pieces of the architecture which are considered de-facto for an SOA. e.g. Service Bus, BPEL process Manager, Business Activity Monitoring etc. But a key component which is only added as an after-thought in most implementations is the Service Registry.

The reason for Service Registry being ignored is the "start-small" approach that most customer's take with SOA Projects.

In this blog, I want to argue that even with small projects, adding a Service Registry in the architecture has significant benefits with regards to Developer Productivity, Build Quality, Ease of maintenance and Architecture Flexibility.

Oracle Service Registry with its out-of-the-box integration/interfaces with Oracle SOA components is the ideal choice for Oracle SOA Projects.

Any Software project would be using several environments like Build, System Test, Stress Test before moving the code to Production. In each of these environments the Service Endpoints would map to systems/applications pertaining to the particular environment. Thus for migrating code to each environment, there has to be a separate code-base created which needs to be updated manually with Service endpoint information specific to that environment. This is usually achieved using ANT scripts, but is a manual task fraught with errors.

Using the Oracle Service Registry, separate registry instances for each environment can be created and approval workflows to promote services from one environment to the next can be configured. With the Service Registry approach, the only reference embedded in the code is the UDDI Service ID. At runtime, this Service ID would be mapped to the appropriate end point Service based on the Service Registry configuration.

Thus a developer is freed from the task of maintaining multiple code bases and creating ANT scripts for every code promotion exercise thus improving Ease of Maintenance & Developer Productivity.

Another key function of the Oracle Service Registry is its role as a central directory for Enterprise Services. Oracle Service Registry plays an important role in SOA Governance and prevention of Service Sprawl by providing approval workflows for Service Provisioning. This encourages more re-use and less re-invention which has a direct impact on Developer Productivity.

Due to the above zero-code & configuration based approach, human error in moving the code from one environment to the next is also reduced drastically leading to better Build Quality. Feeback on Quality of Service is provided by Oracle Service Registry which aggregates and captures quality of service metrics for the deployed services from the Production runtime.

Because of the extra level of indirection provided by the Service Registry, it becomes easy to achieve location independence for endpoint services. The Oracle Service Registry also enables change to the runtime behaviour of the Application by just changing the Registry configuration thus enhancing the Flexibility of the architecture.

Small SOA Projects will thus benefit greatly from using Oracle Service Registry across their Development, Build, Deployment & Production phases.

January 21, 2011

Enterprise Asset Management - Emerging trends

Guest post by
Krishna Ammapalayam Srinivasaragavan, Consultant, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.


We are in the era of Enterprise Resource Planning implementations. It's estimated that by adopting ERP systems and best practices cost reduction, quality improvement, staff skills increases too many folds. Also the IT companies dealing with ERP systems receive the maximum revenue and profit in their operations.

ERP from its start evolved with many techniques of integrating the processes in an industry and to the extent of catering mobile applications from remote places. At start ERP focused on back office works and later started integrating the customer with the Customer Relationship Management techniques.

Oracle E-Business Suite is one of the best ERP packages available in market at present. Oracle EBS evolved with many versions and each time new modules getting added up for making business in industries lot easier. Apart from basic modules like Inventory, Purchasing, Finance, lot of stress is being given on Edge products like eAM, OTM, OTL etc. This blog will throw light on the important features that exist in Enterprise Asset Management module in Oracle EBS R12.

Enhanced features in R12.1 (+) series-

  • Express Work : It's an integrated way of finishing the emergency work quickly with all the details like labor, charge time, material issued entered in single page.
  • Microsoft Project Integration : This will help in integrating the Microsoft project with eAM which in turn used in Work order scheduling in effective manner.
  • Google Maps integration : Apart from maintaining an asset, it's becoming important to track them. eAM has come up with solution of integrating the assets with the web-based Google maps. During asset creation or after we need to provide some geo information such as Longitude, Latitude, and Direction for the Assets to locate.
  • Construction units : This feature is provided under the Maintenance Super User responsibility in OAF. The activities carried out on repetitive jobs like commissioning of Towers, Electric Lines, Power plant construction etc., can be effectively estimated and planned using Construction units.
  • Primavera Integration : One of the products in market dealing with Project management. Integration of Primavera and eAM will help in scheduling eAM work orders for Project based activities.
  • Encumbrance : Long living feature with purchasing modules has been introduced in eAM for Acconting encumbrance with eAM Purchase orders/ Purchase requisitions.
  • Work Permits : Creating only work order without information about operations, manitenance and safety precautions are of no use. eAM has come up with feature called Work permit where we need to take permission before taking up any work along with above details.

For further information on the above features, please refer RCD documents in metalink.

January 3, 2011

Thin Chart of Accounts within OFSAA !

Guest post by
Bhuvaneswari Venkataraman, Lead Consultant - Banking and Capital Markets, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.


In older version of Oracle Financials Service Application 4.5.xx (OFSA), considerable time was spent on designing the Chart of Accounts (COA) to bring out the optimum number of members under COAs. Now with new Oracle Financial Service Analytical Application 5.xx (OFSAA) leveraging its enhanced features like conditional assumptions system can assign any combination at run time instead of pre-defined only leading to thin COAs instead of thick in earlier versions.

Coining of COA is dependent on many factors like requirements on report stratification, granularity of level to which transfer price assumption are to be adhered to, multiple currency etc. Considerable time was spent during requirements stage and design stage to ensure all combinations are captured to ensure optimal number of members under COAs. Now in new OFSAA, there is no need to define such combinations before hand as leveraging conditional assumptions system can assign any combinations at run time.

Let's take an example for better understanding,  consider the case of attaching TP methods to a product with multiple scheme code. In earlier version we needed to factor in scheme code in TP-Product dimension,  so that different TP methods can be attached to different scheme codes of a Product. Typically if we have a product code 11101 and multiple schemes under this product say 101, 102, 103...nnn, we had to coin Product Chart of Accounts as 11101101,11101102 etc so that each combination of product and scheme gets a separate TP method.  But,  now with the availability of Conditional assumption we can attach multiple TP methods to the same product under different segments. Have the Product COA as 11101 only and with conditions Scheme code = 101 TP method 1, Scheme code=102 Method 2 etc., Similarly we can take any other aspect such as maturity date, accounts belonging to a particular product falling under a maturity horizon can have one TP method and another maturity horizon can have a different TP method assigned. This goes on with combination of Product plus available cash-flow characteristic of product. This  gives more flexibility with the number of dimension members drastically reduced.

Above examples clearly articulate how conditional assumptions will help client to have thin COAs providing more flexibility and ease of maintenance.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter