Write back Proof of Concept

8/7/2019 Write back Proof of Concept

http://slidepdf.com/reader/full/write-back-proof-of-concept 1/9

Write back Proof of Concept



Apart from Reporting, OBIEE has an advanced feature which allows entering or updating

the values directly into the database. This feature is called write back. Users with

appropriate permissions can use this feature.This exercise describes the implementation of write back feature in OBIEE.

In order to implement this feature in OBIEE we have to make some changes in therepository and in presentation services.

Step 1:Create a table in which you are trying to implement write back. In this example, I created

a table called customer with the below SQL in dwpd database.

CREATE TABLE "NQSERVER"."CUSTOMER"(

"CUSTKEY" NUMBER(5,0) NOT NULL ENABLE,

"WBVAL" NUMBER

)

Step 2:Imported that table in the rpd.

Renamed the Connection pool to WriteBack. Make the table not cacheable.



Step3:

Dragged it onto BMM layer.

Dragged the same table from physical layer to BMM. This table is just used to join thetable to itself as in our example; this table doesn’t join to any other table in our database.

If we don’t have this, OBIEE will give you error telling that there are no joins in the

subject area. To remove that error, we are just joining this table to itself.

Step4:

Drag the table to Presentation layer. No need of the duplicate table to be in presentationlayer.

Step5:

Check the consistency check and check in the changes.

Step6:

Go to the presentations services and access the table.

Step7:

Drag the column in the criteria and see the results. Now you will see no results because

the table has no data. Populate the table with data in the databse and run the report again.

Step8:

Edit the table view to see:



Step9:

Click the write back properties. Now fill the properties with:

Now you will see:

Notice that you will see c0 and c1 for the columns.

Step10:

Go to properties for the both the columns and select

Leave the field size blank.



Step10:

Once this is done, create a xml.<?xml version="1.0" encoding="utf-8" ?>

<WebMessageTables xmlns:sawm="com.siebel.analytics.web.messageSystem">

<WebMessageTable lang="en-us" system="WriteBackTemplates" table="Templates"><WebMessage name= "CustomerWB">

<XML>

<writeBack connectionPool="WriteBack "><insert> INSERT INTO CUSTOMER VALUES(@{c0},@{c1}) </insert>

<update> UPDATE CUSTOMER SET WBVAL=@{c1} WHERE CUSTKEY =@{c0}

</update>

</writeBack></XML>

</WebMessage>

</WebMessageTable>

</WebMessageTables>

Save it as test.xmlRemember, the template remains the same for all the write back xml. The fields which

are highlighted in red only change according to the requirement.

Here CustomerWB is name of the xml which is referenced in our presentation services.

Write back is the name of the connection pool in the rpd.

Insert and update change according to the requirements. You see c0 and c1 used. Theseare the values used in the report.



Step11: (Only administrator can do this)

Move this xml file to the server where OBIEE is installed. Place it on{Oracle_BI_Home}/web/msgdb/customMessages

Restart the presentation services.

Step12: (Only administrator can do this)

Open the presentation services and go to Setting >Manage Privilages

Change this for the user who wanted to use this option.

Step13:

Make sure in rpd, double click the database name for that table.

Check the above option.

Step14:

Check your results.



Step15:

You can update values but how to implement insert. To implement this, the table in thedatabase must have blank rows. Since the table cannot have blank rows as CUSTKEY is

defined as primary key, we created a separate table in the same database with the same

structure with the below SQL.

CREATE TABLE "NQSERVER"."CUSTOMER_NULL"

("CUSTKEY" NUMBER(5,0),"WBVAL" NUMBER

)

Insert a null row for this table.

Imported this table in physical layer.

Dragged it onto source of the Customer table. Now this table is added as source to the

original table.

Once joined then, Go to Logical table sources and define the fragmentation content for both these tables.





Make sure the condition mentioned will always be true. In our case both 1001 and 1002

exists, so it works fine. If one of the cases fails, then source is not added giving incorrect

answers. So, define the condition, such that it is always true.

Step15:

Check the consistency and save the rpd. Now check the report.

There is an extra row which will help us to insert the record.

Depending on the requirement, your xml file will change and make sure thefragmentation content is always true when you are looking to insert.

Documents

Write back Proof of Concept