Entries from Siebel Essentials tagged with 'upgrade'
Fumbling around with the Oracle BI Message Database
not that quickly There is a high number of posts and documentation available on the internet on how to customize the Oracle BI EE User Interface (example here), namely the content of the xml or other files (css, etc) that make up the Oracle BI message database. More commonly known as the msgdb folders. Storing strings and configuration information in easy-to-change text files is of course a benefit but also a curse. Because unlike information stored in a relational database (such as the Siebel CRM repository) it can not be easily merged during an upgrade to a higher release. So simply overwriting the existing files is not an option as an upgrade would just replace the files with newer versions. To avoid this there is a simple but efficient strategy: Copy the files to a custom folder. The trick is that the Oracle BI Presentation service loads the messages from several folder locations in a specific sequence which is revealed below: OracleBIData\web\msgdb\l_xx\customMessagesOracleBIData\web\msgdb\l_en\customMessagesOracleBIData\web\res\customMessagesOracleBI\web\msgdb\l_xx\messagesOracleBI\web\msgdb\messagesl_xx in the above list stands for the language specific folders. Standard (vanilla) files typically reside in the OracleBI folders, customers are encouraged to copy these files to the OracleBIData folders. So when you want to change the content of a specific string such as "My Dashboard" you would do a text search in the OracleBI folder and find the uimessages.xml file. Before manipulating the file you need to copy it to the OracleBIData\web\msgdb\l_en\customMessages folder (create the folder if it does not yet exist). Now you can safely make changes to the file and restart the Oracle BI Presentation service to verify your changes....
Audit Trail Storage
About large objects with character A while ago during a Siebel CRM upgrade project, a consultant approached me and asked how and why Oracle has changed the data model of Audit Trail from version 7 to version 8. After a brief discussion we found out that he referred to a new column in the S_AUDIT_ITEM table. The column is named AUDIT_LOG and has the data type of CLOB (Character Large OBject - newly supported in Siebel 8.0 and above), which enables it to carry a whopping 2 gigabytes of data for each record. A little bit of investigation reveals that this column stores a string that documents the changes made to the audited record during an update or insert operation. The following screenshot gives you a general idea how this string looks like. click to enlarge In earlier versions of Siebel CRM, the S_AUDIT_ITEM table stored one record for each field that was audited, so the table grew very large. Creating a single string with all fields for each update reduces the size of the table significantly. What was a little unfortunate in the specific project is that they accessed the S_AUDIT_ITEM table with Informatica to incorporate the Audit Trail data into their data warehouse. After the Siebel CRM upgrade, the ETL did no longer work because of the new column. Furthermore, because of the data type of CLOB and the cryptic nature of the string it was impossible to retrieve Audit Trail data with simple SQL. I proposed a solution which encouraged accessing the Siebel business component layer using EAI techniques such as Siebel ASI (Application Services Interfaces) and web services. This would eliminate the need to access the physical table directly. The business component used to display the Audit Trail data is based on a specialized class CSSBCVAuditTrail which makes it a virtual business component. But you can still use it in an integration object and create a read-only ASI. Please find more information about Siebel EAI and ASIs in the Siebel Bookshelf and the Integrating Siebel Applications course. As the more inquisitive among you might have already found out, the data string in the AUDIT_LOG column looks quite familiar to the one that stores the data modifications for Siebel Remote in the S_DOCK_TXN_LOG table (see screenshot below). But this is a different story... click to enlarge...
Oracle BI Applications Upgrade - Part 3
Welcome back, these are the final steps in an Oracle BI Applications upgrade scenario Step 8: Merge the DAC repository After merging the custom folders in the Informatica repository, we have to merge the second (of four) repositories, that is the DAC repository. The new DAC 10.1.3.4 has the unique feature of allowing direct upgrades and merge processes of two existing repositories, even from Siebel Analytics Applications 7.8.4, which had a "non-partioned" repository without containers. Please note that the following steps can only be executed in DAC 10.1.3.4. Previous versions do not support an automated upgrade. Below is a short summary of steps, please see the documentation for more details:Connect to the new standard DAC repository and export the containers you want to upgrade. Connect to the old, customized DAC repository and start the upgrade wizard. Select Refresh Base. This option is recommended when you upgrade from BI Applications 7.9.x Inspect the difference report and resolve conflicts if necessary Click Merge The result is a DAC repository which inherits the modifications made to the standard containers between 7.9.x and 7.9.5 as well as the custom container. However, there might be some additional manual work necessary to complete the DAC upgrade. Step 9: Run test Execution Plans After verifying the Setup view of DAC (registering Informatica servers for 8.1.1 is different) you can rebuild your execution plans and execute test runs to ensure that the ETL works as expected. Step 10: Upgrade and merge the Oracle BI rpd file Number 3... If you have customized the Oracle BI rpd file and you want to benefit from changes made by the Oracle developers, you have to use the equalizerpds utility and the Administration Tool in order to accomplish a merge of the three versionsPrior Customer Repository Prior Standard Repository New Standard Repository into a single New Customer Repository According to the Oracle BI Applications 7.9.5 Upgrade Guide you have to get the original 7.9.x rpd file from the Upgrade folder and copy it to a temporary folder along with your customized rpd and the new standard rpd You then execute the following major stepsuse equalizerpds.exe to resolve minor differences in spelling (such as "Core"."W_DAY_D" is the same as "Core"."W Day D" Compare repositories to find which elements have been created, removed or modified Merge the repositories using the Administration Tools 3-way merge functionality Test the outcome of the merge This concludes the upgrade of repository #3, one more to go... Step 11: Upgrade the Oracle BI Presentation Catalog If you need to combine the changes of Oracle engineering with your customizations (in order to benefit from the new standard list formats for Siebel Marketing, for example) you have to merge the different versions of BI Presentation Catalogs into one. This is supported by the Catalog Manager tool. You have the choice between a simple copy and paste process if you adhered to the best practice of creating your own folders and the merge functionality of Catalog Manager. Conclusion Adhering to best practices and staying "close to the standard" during the development phase is crucial for successful and timely upgrades. Oracle BI Applications get you in touch with 4 different architectures and repositories (Informatica, DAC, rpd and presentation catalog) all of which exist in an original standard, a customized and a new standard version. These are the recommended ways to customize them:Informatica: Only modify objects in custom folders DAC: Only modify objects in the custom container rpd: Trim the original repository and create new presentation catalogs if needed Presentation Catalog: Only modify objects in custom folders Have a nice day...
Oracle BI Applications Upgrade - Part 2
as promised in part 1 of this series, here is part 2 of a summary of steps for an Oracle BI Applications upgrade: Step 5: Import the DAC 7.9.5 repository Use the DAC 7.9.5 client to create a second connection to a new schema and create an empty DAC repository. Import the BI Apps 7.9.5 DAC repository into the new schema using the DAC client. Note: you can not import the 7.9.5 DAC repository using DAC 10.1.3.4 (see below). Optional Step: Install DAC 10.1.3.4 The Data Warehouse Administration Console 10.1.3.4 has been released some time ago. This is an optional step. You can stick with the DAC that comes with Oracle BI Applications 7.9.5 but you might want to look at the new features of DAC 10.1.3.4. However, if you decide to use the new DAC, there is no easy way to revert back (the DAC repository) to 7.9.5, so a good reason to start with taking a backup. Use the new DAC to create connections to the old and new repository and allow DAC 10.1.3.4 to upgrade the schema by logging in to both connections. Quick delta for DAC 7.9.5 to 10.1.3.4 No hibernate libraries required, but make sure you copy the database connectivity .jar file into the lib directory Must create authentication file on first login, then change the Administrator password. For subsequent logins, use the Administrator account. Existing repository (7.9.x) is automatically upgraded to new DAC version upon first login, you can not use earlier DAC versions (this applies to both client and server) after the upgradeStep 6: Upgrade and merge the Informatica Repository Upgrade the old version of the Informatica Repository following the instructions in the Informatica PowerCenter 8.1.1 Installation and Configuration Guide. The process is executed in the web-based Administration Console. Next you can establish connections to both repositories (the one you customized and the new one) in Informatica Repository Manager. You can now compare folders or objects and copy the custom folders to the new repository. If you adhered to the recommendation to do all modifications in custom folders, this is a very safe path. If you made any customizations to objects in standard folders, you most probably have to reapply these changes to the objects in the new repository. Step 7: Upgrade the OBAW Schema According to the OBI Apps 7.9.5 Upgrade Guide you have to run prepared SQL scriptsuse the ddlimp utility to change the schemastart some specialized workflows manually, if you upgraded the Siebel source application to 8.0 or 8.1Reset the sequence generators of Informatica using a scriptImport a specialized repository which contains upgrade workflows and run the respective workflowsNeed a break? All right, see you in a few days for the final. In part 3 we will discuss merging the DAC repository, running test execution plans, upgrade and merge the .rpd file and the presentation catalog....
Oracle BI Applications Upgrade - Part 1
donkey rides Those among you who have undertaken the quest of a Siebel CRM upgrade know what it means to upgrade one (1) repository and merge new standards with old customizations. How does it (look and) feel to upgrade the stunning number of four (4) different repositories, such as in Oracle BI Applications where we currently have 1 Informatica repository1 DAC repository1 BI Server repository1 Presentation Catalog I had the opportunity to do a POC for a custom training and this series of posts tries to point you to the basic steps and pitfalls. The slightly customized BI Application we have to start with consists of the following Oracle BI EE 10.1.3.2Oracle BI Applications 7.9.2 including DACInformatica 7.1.4The target versions are Oracle BI EE 10.1.3.4Oracle BI Applications 7.9.5Informatica 8.1.1 SP4DAC 10.1.3.4 In this first part of the series we cover upgrading the infrastructure basically by installing the new versions of the software packages. However, whenever you undertake an upgrade make sure you read the fabulous manual. And read it before you lay your hands on the keyboard. Step 1: Upgrade the Oracle BI EE Infrastructure This is a straightforward step since you simply install the new version on top of the old version, which is a supported practice even for Siebel Analytics 7.8.4. Of course, you will do a backup of all valuable files and if you modified any standard xml files you better watch out and copy them to the custom folders next time ;-) Step 2: Upgrade Oracle BI Applications Now it's time for another backup, this time you copy the entire DAC directory to a safe place. Next you backup any custom files (scripts, parameter files etc.). We have to uninstall the existing version of Oracle BI Applications and then install Oracle BI Applications 7.9.5. Oracle BI Applications 7.9.5 are "Fusion Edition" Step 3: Upgrade Informatica 7.1.4 to 8.1.1 SP4 Oracle BI Applications 7.9.5 come with exclusive support for Informatica 8.1.1 SP4 which is a bit of a challenge as 8.1.1 has a completely different server architecture (see delta summary below). Best thing is to carefully follow the pre-upgrade steps in the Informatica PowerCenter 8.1.1 Installation and Configuration Guide, especially creating another database (or schema) for the new repository Backup time again. This time we take care of the existing repository and the Repository Agent configuration file (.cfg). Then we uninstall previous versions of Informatica Servers and Clients and install Informatica Services and Clients 8.1.1 and apply SP4 immediately afterwards. The installer creates the new repository service, make sure you name it different than the previous repository. Caveat: Note that the install.exe might not launch if a java-based process such as Oracle's Enterprise Manager Console is running. Quick Delta for Informatica 7.1.4 to 8.1.1 SP 4 (Windows) No separate windows services for Informatica server and Informatica Repository Server New "wrapper" service: "Informatica Services 8.1.1" Server administration now done completely in a web client Repository service and Integration Service (formerly known as Informatica server) are administered from the central web-based administration console New concept of domains, which contain nodes, which host processes such as repository and integration services. The web-based Informatica administration console in version 8.1.1 Step 4: Configure the new Informatica 8.1.1 Services Follow the steps in the Oracle BI Applications 7.9.5 Installation Guide to set up the basic infrastructure. Import the new version of the Informatica Repository provided by the BI Apps 7.9.5 installer into the new Informatica 8.1.1 database. Copy the source and lookup files to the correct directories. Set PowerCenter properties according to the guide. That's it for today, stay tuned for Part 2 where we will install DAC 10.1.3.4, upgrade the Informatica repository and the BAW schema....
Close to the Standard
"Once bitten, twice shy" If you have the opportunity to observe some of the Siebel CRM projects (or any other standard enterprise software project) across the globe, however small or large they may be, there is a familiar pattern: Phase of enthusiasm Learning phase, along with the assurance to "stay close to the standard"Pilot phase during which most of the requirements become clear (and complex)Land of oblivion (where the first thing to be forgotten is the promise of 2.)Regression to coding (believing that writing custom code can solve all problems faster and easier than standard functionality) These are some typical phases (hope you also note the satirical aspect) that a typical project goes through. However, we are talking about standard software, which means frankly that the customizing developers at the customer site find themselves in a race against time and hundreds of developers in the Oracle offices who are determined to create another splendid version (Siebel 8.1 is just around the corner these days). So when a project has matured and all requirements are solved, the upgrade project typically comes next. And it is during the first attempts to upgrade the more or less customized application to the newest version when the whole thing seems to blow up (# 5. of the above list being reason #1 for the blow-up in most cases). So we can add to our list 6. a phase of frustration 7. the vow to stay closer to the standard after the upgrade, which is immediately followed by 8. the requirement to upgrade the application (which is complex) 9. The land of oblivion... - we had that before ;-) To cite a customer: "What does 'close to the standard' mean? How can we solve our very complex requirements if we are not allowed to add custom code? How can we customize the applications and remain upgradeable?" The answer to the first question: "Thoroughly observe and clearly understand the standard functionality and metadata and when you implement solutions, let your developers behave the same way the developers at Oracle do." Let's elaborate on this using the Siebel CRM Repository as an example. Since Siebel 7 was brought on the market in 2001, we can observe that any new module (e.g. Siebel Loyalty in 7.7, Customer Order Management in 7.8), however complex its functionality may be, can be dissected into the following: 1. The basic objects Metadata objects like applets, business components and tables which allow users and EAI processes to create, read, update or delete data needed for the new module. The Siebel Essentials or Core Consultant Course teaches how to create and modify these objects and how they refer to each other. The following is a chart familiar to those who benefited from these courses Summing up, we can say that adding or modifying objects of these 10 basic types is "close to standard" because this is exactly the way how the standard application is created. OK, we now have nice views and applets and they allow us to read and manipulate data. But how does the additional functionality come in here? The answer is: 2. Business Services These are metadata objects which (since Siebel 2000) serve as globally accessible capsules of functionality (i.e. code). So whenever an Oracle developer is asked to implement some functionality that is not available in the current application, he or she will write code and place it in the repository as a business service. This is in fact the answer to the second question: You are indeed allowed to write custom code, but you should have it written as a business service" and - being a loyal Oracle University instructor - I would add "And your developers can learn how to do this in the Siebel Scripting Workshop." A quick look at the current standard Siebel CRM repository (SIA 8.0) reveals a rich library of more than 1000 highly reusable and well-documented (along with many not-at-least-documented - keep your fingers off those) business services. List of business services in Siebel Tools OK, so we now have the data access and reusable services, but what if I need to call these services one after the other and combine them with my custom code. This leads us to the 3rd ingredient of standard Siebel CRM applications: 3. Workflows Siebel Workflow allows developers to combine classic Siebel operations like creating or updating records with standard or custom business services along with decision logic and exception handling. Siebel Workflow is highly scalable and tests have proven a very high performance (outdoing scripted code by factors). The tool of choice of Oracle developers to orchestrate reusable services into, yes, yet another service (that's what a workflow really is: just another service which you can call from literally anywhere) is Siebel Workflow. Open the list of standard workflows in Siebel Tools and see for yourself. The current version (SIA 8.0) comes replete with more than 1000 standard workflow processes for literally any kind of functionality such as pricing, integrating with SAP, marketing or customer-facing processes such as quote-to-cash or forgotten passwords. Example for a standard workflow Summary (= Answer to the third question and I will make this short): Focus your customizing investment on the 10 basic objects, business services and workflow and your project is close to the standard and therefore easily upgradeable....
Search All Blogs
Google Search
Feed Subscription
If you use an RSS reader, you can subscribe to a feed of all future entries tagged 'upgrade'.
