Disclaimer

All of the topics discussed here in this blog comes from my real life encounters. They serve as references for future research. All of the data, contents and information presented in my entries have been altered and edited to protect the confidentiality and privacy of the clients.

Various scenarios of designing RPD and data modeling

Find the easiest and most straightforward way of designing RPD and data models that are dynamic and robust

Countless examples of dashboard and report design cases

Making the dashboard truly interactive

The concept of Business Intelligence

The most important concept ever need to understand to implement any successful OBIEE projects

Making it easy for beginners and business users

The perfect place for beginners to learn and get educated with Oracle Business Intelligence

Tuesday, August 19, 2014

OBIEE: Dynamically calculate quarterly difference without using time series function

Sometimes, you have a custom report built from custom schema, it could be a materialized view or view that were custom made, where the number is at a certain granularity without hierarchy defined. Like you have a quarterly report, but now the requirement is to display the numbers not only in the quarter that user pick, but also display the previous quarter of that user defined quarter along. Not only that, you also need to display the difference between the quarters as well as the monthly measures under these 2 quarters. Like the report below for instance:





As you can see from the report, the user just pick 2014 Q3 and the report comes back with Q3 as well as Q2 data with month and quarter column pivoted. Now the pivot view allows us to get the total per quarter, which as you can see, is done. Now the challenge is, how are we going calculate the difference between these 2 quarterly difference?


So, let me go back a little bit. Before I got to the report was you can see, I created a new column in the RPD which brings Year and Quarter concatenated based on what this table have. In other words, i take '2014' and '3', then concatenated it 'Q' in the middle to get you 2014 Q3. 'Trim' function is used here to get rid of any unwanted spaces that is trailing as a result of converting number into string.


The next step I decided to do is to create a simple report which takes the user input quarter value, then it should return that quarter value as well as the previous quarter value using the rpd column that I just created above.


In the above report, 'Current Year Quarter' is nothing but the RPD column, the Previous Year QTR has the following formula that returns the previous Quarter:

Since the time dimension does have Date (DATE_VALUE) column, by doing timestampadd at month level with '-3' will automatically give you the month that is 3 month prior to the month of that corresponding DATE_VALUE. It also needs to address the fact that the prior quarter of Q1 should be Q4 of the previous year, therefore a case statement is embedded to take care of this situation:

TRIM(TRAILING ' ' FROM CAST(case when "- XXFB_TIME_DIMENSION"."QUARTER" = 1 then "- XXFB_TIME_DIMENSION"."YEAR" - 1 else "- XXFB_TIME_DIMENSION"."YEAR" end AS CHAR))||' '||'Q'||Trim(trailing ' ' from cast(QUARTER_OF_YEAR(timestampadd(sql_tsi_month,-3,"- XXFB_TIME_DIMENSION"."DATE_VALUE")) as char))

After concatenating these components together, it finally gives me what I want:


This report will be accepting the presentation variable from the dashboard prompt quarter, so i call it 'Quarter'. Save this report as 'Previous Quarter'.

Now, go back to the main report that I have been creating as you can see below:



Here in the filter section, the Year&Quarter column (which is the new RPD column) is getting value from 'Current Year Quarter' OR from 'Previous Year Column' of the report 'Previous Quarter' created above. This means that when user select 2014 Q3 from the dashboard, it will return 2014 Q3 and 2014 Q2, both will be passed to year&quarter column of this report through this filter condition. Then by pivoting the quarter and month column, it will display the view that you saw.

Now the second thing is to come up with a way to calculate difference of these 2 quarters. Unfortunately, this will have to be done with a different calculation because time series function will make it very complicated and difficult to validate the logic.

So first thing is to find a way to calculate the measure for each of the quarter and it's previous quarter. This can be done using 'filter' function by making the Year&Quarter column equal 'current quarter' or 'previous quarter' from report 'Previous quarter'.


As it turns out, OBIEE does allow to use filter function with nested query, so this is what the expression looks like below:

FILTER(ifnull(FACT."Accounted Net USD",0) + ifnull(FACT."Accounted Net USD",0) USING ("- XXFB_TIME_DIMENSION"."Year&Quarter" IN (SELECT saw_0 FROM (SELECT "- XXFB_TIME_DIMENSION"."Year&Quarter" saw_0, TRIM(TRAILING ' ' FROM CAST(case when "- XXFB_TIME_DIMENSION"."QUARTER" = 1 then "- XXFB_TIME_DIMENSION"."YEAR" - 1 else "- XXFB_TIME_DIMENSION"."YEAR" end AS CHAR))||' '||'Q'||Trim(trailing ' ' from cast(QUARTER_OF_YEAR(timestampadd(sql_tsi_month,-3,"- XXFB_TIME_DIMENSION"."DATE_VALUE")) as char)) saw_1 FROM "FB - Custom Views for Oracle Financials" WHERE "- XXFB_TIME_DIMENSION"."Year&Quarter" IN ('@{Quarter}')) nqw_1 ))) -  FILTER(ifnull(FACT."Accounted Net USD",0) + ifnull(FACT."Accounted Net USD",0) USING ("- XXFB_TIME_DIMENSION"."Year&Quarter" IN (SELECT saw_1 FROM (SELECT "- XXFB_TIME_DIMENSION"."Year&Quarter" saw_0, TRIM(TRAILING ' ' FROM CAST(case when "- XXFB_TIME_DIMENSION"."QUARTER" = 1 then "- XXFB_TIME_DIMENSION"."YEAR" - 1 else "- XXFB_TIME_DIMENSION"."YEAR" end AS CHAR))||' '||'Q'||Trim(trailing ' ' from cast(QUARTER_OF_YEAR(timestampadd(sql_tsi_month,-3,"- XXFB_TIME_DIMENSION"."DATE_VALUE")) as char)) saw_1 FROM "FB - Custom Views for Oracle Financials" WHERE "- XXFB_TIME_DIMENSION"."Year&Quarter" IN ('@{Quarter}')) nqw_1 )))

Now the break down of this expression is below:

(Below will get you Current month measure)
FILTER(ifnull(FACT."Accounted Net USD",0) + ifnull(FACT."Accounted Net USD",0) USING
("- XXFB_TIME_DIMENSION"."Year&Quarter" IN
----- (The red part is the measure that we are dealing with)


(SELECT saw_0 FROM (SELECT "- XXFB_TIME_DIMENSION"."Year&Quarter" saw_0, TRIM(TRAILING ' ' FROM CAST(case when "- XXFB_TIME_DIMENSION"."QUARTER" = 1 then "- XXFB_TIME_DIMENSION"."YEAR" - 1 else "- XXFB_TIME_DIMENSION"."YEAR" end AS CHAR))||' '||'Q'||Trim(trailing ' ' from cast(QUARTER_OF_YEAR(timestampadd(sql_tsi_month,-3,"- XXFB_TIME_DIMENSION"."DATE_VALUE")) as char)) saw_1 FROM "FB - Custom Views for Oracle Financials" WHERE "- XXFB_TIME_DIMENSION"."Year&Quarter" IN ('@{Quarter}')) nqw_1 )))  
---- this is the other report that we created earlier, presentation variable needs to be entered here, saw_0 represent 'current year and quarter' from that report

 -
(Below will get you previous month measure)
FILTER(ifnull(FACT."Accounted Net USD",0) + ifnull(FACT."Accounted Net USD",0)

USING ("- XXFB_TIME_DIMENSION"."Year&Quarter" IN

(SELECT saw_1 FROM (SELECT "- XXFB_TIME_DIMENSION"."Year&Quarter" saw_0, TRIM(TRAILING ' ' FROM CAST(case when "- XXFB_TIME_DIMENSION"."QUARTER" = 1 then "- XXFB_TIME_DIMENSION"."YEAR" - 1 else "- XXFB_TIME_DIMENSION"."YEAR" end AS CHAR))||' '||'Q'||Trim(trailing ' ' from cast(QUARTER_OF_YEAR(timestampadd(sql_tsi_month,-3,"- XXFB_TIME_DIMENSION"."DATE_VALUE")) as char)) saw_1 FROM "FB - Custom Views for Oracle Financials" WHERE "- XXFB_TIME_DIMENSION"."Year&Quarter" IN ('@{Quarter}')) nqw_1 )))
 --- saw_1 represents the 'previous year and quarter' from that report 

Now, test the new report:



It's working nicely..

Thanks

Friday, August 1, 2014

OBIEE vs Tableau Report

Having used both technologies quite extensively, I can't help but to make some comparisons between the 2 tools.

For those that are not quite familiar with Tableau, it is a pretty cool technology that also provides very good look and feels of the reports. It is a pretty popular technology in a lot of companies.

Here are some of the cool things that tableau has to offer:
1.
Tableau allows developers to bypass the metadata design and go directly into the report building phases. In other words, there is no equivalence of Admin Tool in Tableau. You develop your SQL or PL/SQL, you then create reports and views based on this SQL. This allows the development to be very flexible because there is no needs for dimensional modeling. You can join as many tables, create as many self-joins, making as many snowflake or normalizations of dimensions as you want, as long as your query is giving you the right data, you can put it in tableau and it becomes the report you want. The same thing in OBIEE would probably have to be done through custom views or materialized views, which will still need to be migrated across the 3 layers in Admin tool.

2.
Tableau makes mapview much easier to build. All you need is spatial data in your table: latitude and Longitude and city. Once these fields are in your query, it will show up in tableau with different Icons letting you know they are available. You can then putting in the mapview and the map will be generated with every city in your table on the map. This process is much simpler than doing the same in OBIEE.

3.
The latest versions of Tableau provides your calender for any date filters (I am surprised it took this long for such important feature to come up ). The date filter has some pretty cool features that it allows users to not only filter based on dates, but also provides other filtering options such as 'last 2 weeks', 'last 2 months', 'between each Monday' with all just a click away. This can also be done in OBIEE but will require the use of variables, which will table some engineering.

4.
Tableau report allows users to pick their own filters while viewing the report. In OBIEE, the user will normally have to contact the report developers if they want to change filters and prompts.

5. The common features that OBIEE has, such as agents and navigation among reports and views can also be found in tableau.

6 Tableau is less complicated in its server architecture compared with OBIEE and weblogic.

On the other hand, there are some downside of tableau as well compared with OBIEE:

1.One of the main thing about Tableau is that it doesn't seem to have a query engine. This means it will try to query the entire DB first before applying any filters. This will cause a lot of overheads and oftenly at a enterprise level of reporting, the Tableau server is less stable than OBIEE because of the size of the Data they are dealing with.

2.For enterprise reporting, there might be reports that has to go through auditing to meet certain compliance based on the formatting and other things. OBIEE reporting has been tested for this purpose while Tableau will still have to be trialed and tested. What's the use of having all of the fancy reports that don't pass the auditing?

3.Another disadvantage of Tableau, which can be major for some companies, is that it doesn't allow writebacks. We all know that OBIEE has a writeback feature, which allows report users to update records on the dashboard without having to go to DB. This can be important in a lot of the financial reporting that the users typically would want to update certain records during their month-end closing. This feature is absent in Tableau.

Overall, Tableau is more of a point solution rather than enterprise-wise solution like OBIEE. But Tableau is way less costly than OBIEE and much more flexible in it's design, which also means that the level of SQL Programming for Tableau is much higher than in OBIEE.

I hope this helps

 

Friday, July 25, 2014

How to report on 2 datasets across different database in OBIEE

Hello

Today I want to talk about this feature in OBIEE that allows you to do cross-db reporting, which I think is pretty cool.

Say you have 2 different result sets, they could be 2 tables or could be 2 queries. Now I want to see an OBIEE report that joins these 2 result sets based on some common dimensions, so how do we do it?

First of all, these 2 objects will be residing on different physical folders with different connection pools, this makes it complicated if you want to do physical joins.

In my example below, I have created 2 oblique views that contents 2 SQL queries, but they are located in 2 different physical folders:


Table1 is GL_Balance, which is from 1 DB and table 2 is A_GL_Balance, which is from another DB..

Both tables are actually SQL queries which already contents dimensions and measures from multiple DB tables.


Now in order to create a report that queries both table across the DB, I will leave these 2 tables as it is in the physical layer, but in the logic layer, I will create a logical confirm dimension that separates the dimensional attributes from the measures.  So in the BMM layer, it will become 3 tables, F1, F2 and D. F1 will only have begin_bal and close_bal from Table1 and F2 will have only Balance_Acct_Amt and Balance_Loc_Amt from Table2. Then D will have all of the attributes mapped to both physical tables, you can both this in any BMM folder.





Now in the dimension table, I will map the logical columns to both physical table as sources, which means this table will have 2 LTRs and each columns will have 2 sources mapped to:


You can see that this table has 2 LTRs and each column (company for instances) is mapped to 2 sources..

The rest are pretty standard process, I will create a logical hierarchical dimension out of this table, set the hierarchy level at each fact and move everything into the presentation layer.


The reason I am putting all of the attributes in this table is because I want OBIEE to join these 2 datasets based on all of them, i think they are all common to one another. You can identify which columns are common between the 2 in your case and choose the right list.

What OBIEE does at run time is that, it creates 2 queries that execute in each DB to get the results seperately, it then merge them together in one report.

So I am creating a simple report by picking company and 1 measure from each table


The resulting data:



Now the query log shows the following:

The blue parts are just the SQL that each table was generated by.

]]
[2014-07-25T19:19:03.000-07:00] [OracleBIServerComponent] [TRACE:2] [USER-18] [] [ecid: 1710f6cbdf3264b0:6b7606d0:1476ec8e12a:-8000-00000000000061e2,0:1:9:5] [tid: eb631940] [requestid: 54700010] [sessionid: 54700000] [username: ] -------------------- Sending query to database named Omega Custom (id: <<1390911>>), connection pool named Omega Custom CP, logical request hash , physical request hash 8d6cb66e: [[

select sum(T2060476.BEGIN_BAL) as c1,
     T2060476.SEGMENT1 as c2
from
     (select 
gcc.concatenated_segments, 
gcc.segment1,
gcc.segment2,
gcc.segment3,
gcc.segment4,
gcc.segment5,
gcc.segment6,
gcc.segment7,
gcc.segment8,
gcc.enabled_flag ,
gcc.end_date_active, 
gb.period_name,
gb.currency_code,
gb.translated_flag,
fv.flex_value_set_id
--,gcc.segment3||'-'||gcc.segment1||'-'||gcc.segment6 combo,
,(NVL(gb.begin_balance_dr, 0) - NVL(gb.begin_balance_cr, 0)) begin_bal
, (NVL(gb.period_net_dr, 0) - NVL(gb.period_net_cr, 0)) period_net
, ((NVL(gb.begin_balance_dr, 0) - NVL(gb.begin_balance_cr, 0)) + (NVL(gb.period_net_dr, 0) - NVL(gb.period_net_cr, 0))) close_bal
/*, (NVL(gb.begin_balance_dr, 0) - NVL(gb.begin_balance_cr, 0))) begin_bal
, SUM((NVL(gb.period_net_dr, 0) - NVL(gb.period_net_cr, 0))) period_net
, sum(((NVL(gb.begin_balance_dr, 0) - NVL(gb.begin_balance_cr, 0)) + (NVL(gb.period_net_dr, 0) - NVL(gb.period_net_cr, 0)))) close_bal */
from 
gl_balances gb, 
gl_code_combinations gcc, 
fnd_flex_values fv
where gcc.code_combination_id = gb.code_combination_id
and gb.actual_flag='A'
and gb.currency_code !='STAT'
and gcc.segment2 = fv.flex_value
--and gcc.segment3 like '213530'
--and gb.translated_flag IS NULL
--and gcc.segment1 like '304'
--group by gcc.segment3||'-'||gcc.segment1||'-'||gcc.segment6
order by 4
) T2060476
group by T2060476.SEGMENT1
order by c2

]]
[2014-07-25T19:19:03.000-07:00] [OracleBIServerComponent] [TRACE:2] [USER-18] [] [ecid: 1710f6cbdf3264b0:6b7606d0:1476ec8e12a:-8000-00000000000061e2,0:1:9:5] [tid: eb631940] [requestid: 54700010] [sessionid: 54700000] [username: ] -------------------- Sending query to database named Oracle Data Warehouse (id: <<1390933>>), connection pool named Oracle Data Warehouse Connection Pool, logical request hash 5f0261e4, physical request hash 597bac0c: [[

select sum(T2060495.BALANCE_ACCT_AMT) as c1,
     T2060495.COMPANY as c2
from
     (Select
C.GL_ACCOUNT_NAME,
C.ACCOUNT_SEG1_CODE COMPANY,
C.ACCOUNT_SEG2_CODE COST_CENTER,
C.ACCOUNT_SEG3_CODE ACCOUNT,
C.ACCOUNT_SEG4_CODE PRODUCT,
C.ACCOUNT_SEG5_CODE PROJECT,
C.ACCOUNT_SEG6_CODE INTERCOMPANY,
C.ACCOUNT_SEG7_CODE GEOGRAPHY,
C.ACCOUNT_SEG1_CODE FUTURE2,
A.MCAL_PERIOD_NAME,
B.BALANCE_ACCT_AMT,
B.BALANCE_LOC_AMT
from
W_MCAL_PERIOD_D A,
W_GL_BALANCE_F B,
W_GL_ACCOUNT_D C
WHERE A.ROW_WID = B.BALANCE_DT_WID
AND B.GL_ACCOUNT_WID = C.ROW_WID
) T2060495
group by T2060495.COMPANY
order by c2


So what OBIEE does is that it gets the result from each query individually, then at the server level, it merges the 2 dataset into one report..

The caveat here is that, if each query brings back huge data set, then this technique should be used with caution as it may kill performance during the merging..

Thanks

Until next time

Wednesday, June 25, 2014

How to update report and automatically store updated by and updated time through writeback in OBIEE

Today I am going to talk about writeback in OBIEE. As you know, writeback is a feature in OBIEE that allows users to update reports that they see in OBIEE without having to deal with the ETL process and reloading table. 

There can be reasons why users would want to be able to update the records they are seeing in the report. There could be a known error that users are aware of in their accounting system that is producing the wrong Journal Entries that they are seeing, long term solution will be to correct the data from the system, but for auditing purposes at quarter-end, they are just going to manually update the record through OBIEE report so that the numbers will balance out. 

Another user case can be to have users manually update their username and password in OBIEE on their own. I know that in big enterprises, the user credentials are typically synchronized with their other credentials so it would not likely to have such requirement to let users change their passwords, but in some cases where you may have external users who are not part of the company, they may want to have their own password that can be changed. They can do so by using writeback against the user table to have username and password fields updated.

Anyways, the set up of writeback is pretty standard, which I am not going to get in too much details. Google around and you will find many articles that shows you how to do so. Basically, it comes down to the following steps:

1.you update the instanceconfig.xml file to enable writeback feature. 

2. Enable writeback on the columns you want in rpd (BMM Layer)

3. Give permissions to the application roles to have writeback, done in RPD. (Check permission identity manager and presentation column)

4. Create writeback template and save it as writeback.xml file and put it in following directory in the obiee server machine  /opt/app/OBIEE/instances/instance1/bifoundation/OracleBIPresentationServicesComponent/coreapplication_obips1/analyticsRes/customMessages/  
 
5. Unable writeback in presentation service by checking the setting in column property

6. Define writeback template name in table properties (Only Table view setting)

So here I am only going to talk about step 4, how to create writeback template so that not only it updates the columns, but also it automatically update the username and timestamp when any user executes the writeback.

In my case I have 7 update-able columns, and I have created 3 columns to help with the writeback: last_updated_by, last_updated_date, record_ID. Last_updated_by will store a default system generated value initally and Last_Updated_Date will store the system timestamp of the day that data was loaded to the table through ETL. Record_ID is like Row_ID, it is a unique identifier of each row of the table. 

With the requirement, I am first creating my report in OBIEE 

Noticed I added a new column called 'User'. The expression of this column is 'VALUEOF(NQ_SESSION.USER)', this gives you the user ID of the user who is using the report (and of course, who is likely going to update record next). If you have successfully configured user authentications in rpd, you will have this session variable, it could be named differently in your environment. 

In Advance Tab, you will find the XML code for this report, there you will pick up the column ID for each of the columns you are interested. I will show you an easy way to identify the column IDs:

So here is a part of the entire XML code:



Now if I want to find the column ID of Record ID, I will then do control+F and type 'Record ID' in my search box. You will find the column name highlighted by the computer search, then find the column_ID right above this column name, it will be the column ID of this column name:

Note: Record_ID is the physical column name and Record ID is the displayed column name that I made:

Using this method, I have found all of the column IDs of the columns that I am interested. 

Now let's start writing the writeback template:


Template:





 ------ The name of your template, you name it however


 ---- This is the name of connection pool that your physical table 

SELECT NULL from DUAL                                                        
UPDATE fa_table SET JE_CATEGORY = '@{c4532bb3c8bf3fa07}', COST_CENTER = '@{c2133b77cfebd0a7c}', PRODUCT = '@{cfd5c9816d8ca43fa}' ,
PROJECT = '@{c06bafe4ddddd622e}', GEOGRAPHY = '@{c55fdf58fcd9b827e}', FUTURE2 = '@{c44356274c12d521f}', YES_NO = '@{c1e7217420772545b}', LAST_UPDATED_BY = '@{cf5dd00aa4eeabdf3}',
LAST_UPDATED_DATE = sysdate
WHERE RECORD_ID= @{c70c57d49eba128a6}  









Let's talk about this part:

UPDATE fa_table SET JE_CATEGORY = '@{c4532bb3c8bf3fa07}', COST_CENTER = '@{c2133b77cfebd0a7c}', PRODUCT = '@{cfd5c9816d8ca43fa}' ,
PROJECT = '@{c06bafe4ddddd622e}', GEOGRAPHY = '@{c55fdf58fcd9b827e}', FUTURE2 = '@{c44356274c12d521f}', YES_NO = '@{c1e7217420772545b}', LAST_UPDATED_BY = '@{cf5dd00aa4eeabdf3}',
LAST_UPDATED_DATE = sysdate
WHERE RECORD_ID= @{c70c57d49eba128a6}

fa_table is the physical table name. The following 7 columns are to be update-able by users:

JE_CATEGORY, COST_CENTER, PRODUCT, PROJECT, GEOGRAPHY, FUTURE2, YES_NO

So each of these columns are equal it's column ID.

Now column LAST_UPDATED_BY = cf5dd00aa4eeabdf3. This column ID is not for last_updated_by, it's actually the column ID for column USER. The column ID of last_updated_by is never used.

The idea here is that last_updated_by will be updated with the value of column USER, which is the username of the session. 

Now last_Updated_Date = sysdate. This means whenever user is updating the record, it's happening at the present moment, therefore this column will be updated with whichever date the update happens.

In the where clause I am using record_id as the criteria because I want to ensure that when user makes an update, the update is only applied to 1 row, not a whole bunch of rows. Without record_id in the where clause, then when user updates cost center record, then all of the rows with the same cost center name that the user is trying to modify will get updated. 

After putting this writeback.xml in the right place and restarting OBIEE, let's go back to the report. Here it is import to uncheck the writeback on column last updated by and last updated on:



Define the template name in the table view properties:

Now let's run the report and make some updates:



Updating JE Catogory with random stuff:


After done and the record is updated. Moreover the last_updated_by column is automatically updated with my username.


Now it is important to sort the report based on record ID column. Because every time you update a text field with different value, the row will be re-sorted because text field is always going alphabetically. To avoid having your updated record 'disappeared' on you after you save, just sort your report by record ID.

Thanks and until next time.
 

Tuesday, June 3, 2014

About Merging 2 rpd in OBIEE -- The only article that matters

Hello All

About merging rpds. You all know this merge button under 'file' in Admin tool right?

This launches the merge repository wizard, which is easy.

The confusing part is, how to determine original master rpd, Modified rpd, Current Rpd?

This is what I do to remember:

Let's say there is a scenario that I have RPD1 and RPD2. I want to merge these 2 rpds so that there will be a new RPD that has both RPD1 and RPD2 objects. 

In this case (or any case), you need to create a new rpd with nothing in it. basically a dummy rpd, call it RPD(Dummy)3.

Now open either RPD1 or RPD2, which one doesn't matter, but once it's opened, use the merge button from that rpd to start merging. Therefore, the rpd that is currently opened (so that you can click 'merge' button from it) will automatically be your 'Current' RPD.

Pick RPD(Dummie)3 as your original master rpd and the other RPD (RPD 2 or RPD1) as your modified RPD, then merge..

To make it simple, when merging RPD1 and RPD2 into RPD3, this is the identification in the merging wizard:

Dummy RPD (empty RPD made by you ) = Original Master RPD

RPD1 or RPD2 = Current RPD

RPD2 or RPD1 = Modified RPD

Save Modified RPD AS: Give the resultant RPD a name and location as you wish =  RPD4.

RPD4 becomes the finishing product of this merge and you can leave Dummy rpd there for your next merge.

In the merging strategy step, if you are ever in doubt whether to select 'Current' or 'Modified', just see which rpd did these red objection come from.
In my case, all of the are from 'Current Repository', so in decision list, I pick current for all.


Let the application take care of the rest after you hit 'Finish' when you are finished selecting decisions.

Note:
The merging of rpds can take a while. If one of the RPD is 20MB, the whole merging process can take up to 3 hours.

Try to have 2 rpds that are completely unrelated with each other when merging. A lot of time, merging is unreliable, specially in this version, you never know what has gone missing after merging. If RPD1 and RPD2 have absolutely nothing in common, then the merging of the two might minimize the risk of conflict during merge. If both rpds have a lot in common, I don't recommend merging. Its easier to manually reconcile the difference than to merge.


Thanks 

Until next time

Related Posts Plugin for WordPress, Blogger...