Configure for Write-back in Analyses and Dashboards

Users of a dashboard page or an analysis might have the ability to modify the data that they see in a table view.

This ability is often referred to as "write back." As the administrator, you assist the content designer in configuring write back for users.

The following sections provide information about how to configure for write back:

About Write-back for Administrators

Write-back enables users to update your data directly from dashboards and analyses.

Users with the Write Back to Database privilege see write-back fields as editable fields in analyses. The values they enter are saved to the database. Users without the Write Back to Database privilege, see write-back fields as read-only fields.

If a user types a value in an editable field and clicks the write-back button, then the application runs the insert or update SQL command defined in a write-back template. If the command succeeds, the analysis is updated with the new value. If there's an error either reading the template or running the SQL command, an error message is displayed.

The insert command runs when a record doesn't yet exist and the user enters new data into the table. In this case, the user typed in a table record where the original value was null. The update command runs when a user modifies existing data. To display a record that doesn't yet exist in the physical table, you can create another similar table. Use this similar table to display placeholder records that a user can modify.

Note:

When you create write-back templates, you must include both an insert command and an update command, even if they're not both used. For example, if you're only performing an insert, you must include an empty update statement <update></update>, as in this XML code:

Here's a sample write-back XML file that contains two insert commands and two empty update statements. To find out more about how to create and structure write-back XML files, see Create Write-Back Template Files.

<?xml version="1.0" encoding="utf-8" ?>
<WebMessageTables xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="oracle.bi.presentation/writebackschemas/v1">
<WebMessageTable lang="en-us" system="WriteBack" table="Messages">
   <WebMessage name="SetQuotaUseID">
      <XML>
         <writeBack connectionPool="Supplier">
            <insert>INSERT INTO regiontypequota VALUES(@{c5f6e60e1d6eb1098},@{c5d7e483445037d9e},'@{c3a93e65731210ed1}','@{c6b8735ea60ff3011}',@{c0432jkl53eb92cd8})</insert>
            <update></update>
         </writeBack>
      </XML>
   </WebMessage>
<WebMessage name="SetForecastUseID">
      <XML>
         <writeBack connectionPool="Supplier">
            <insert>INSERT INTO regiontypeforecast VALUES(@{c83ebf607f3cb8320},@{cb7e2046a0fba2204},'@{c5a93e65d31f10e0}','@{c5a93e65d31f10e0}',@{c7322jkl93ev92cd8})</insert>
            <update></update>
         </writeBack>
      </XML>
   </WebMessage>
</WebMessageTable>
</WebMessageTables>

Enable Write-back in Analyses and Dashboards

Administrators can enable users to edit the data in analyses and dashboards.

Set up your semantic model.

Note:
Follow these steps if you use Model Administration Tool to develop semantic models. If you use Semantic Modeler, see
Enable Write Back On Columns.
1. In Model Administration Tool, open your semantic model (.rpd file).
2. In the Physical layer, double-click the physical table that contains the column for which you want to enable write-back.
3. On the General tab of the Physical Table dialog, ensure that Cacheable isn't selected. Deselecting this option ensures that Presentation Services users can see updates immediately.
4. In the Business Model and Mapping layer, double-click the corresponding logical column.
5. In the Logical Column dialog, select Writeable, then click OK.
6. In the Presentation layer, double-click the column that corresponds to the logical column for which you enabled write-back.
7. In the Presentation Column dialog, click Permissions.
8. Select the Read/Write permission for the appropriate users and application roles.
9. Save your changes.

Create an XML document with your write-back template (or templates). See Create Write-Back Template Files.

Your XML document can contain multiple templates. This example shows an XML document that contains two templates (SetQuotaUseID and SetForecastUseID).

<?xml version="1.0" encoding="utf-8" ?>
<WebMessageTables xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="oracle.bi.presentation/writebackschemas/v1">
<WebMessageTable lang="en-us" system="WriteBack" table="Messages">
   <WebMessage name="SetQuotaUseID">
      <XML>
         <writeBack connectionPool="Supplier">
            <insert>INSERT INTO regiontypequota VALUES(@{c5f6e60e1d6eb1098},@{c5d7e483445037d9e},'@{c3a93e65731210ed1}','@{c6b8735ea60ff3011}',@{c0432jkl53eb92cd8})</insert>
            <update>UPDATE regiontypequota SET Dollars=@{c0432jkl53eb92cd8} WHERE YR=@{c5f6e60e1d6eb1098} AND Quarter=@{c5d7e483445037d9e} AND Region='@{c3a93e65731210ed1}' AND ItemType='@{c6b8735ea60ff3011}'</update>
         </writeBack>
      </XML>
   </WebMessage>
<WebMessage name="SetForecastUseID">
      <XML>
         <writeBack connectionPool="Supplier">
            <insert>INSERT INTO regiontypeforecast VALUES(@{c83ebf607f3cb8320},@{cb7e2046a0fba2204},'@{c5a93e65d31f10e01}','@{c5a93e65d31f10e0}',@{c7322jkl93ev92cd8})</insert>
            <update>UPDATE regiontypeforecast SET Dollars=@{c7322jkl93ev92cd8} WHERE YR=@{c83ebf607f3cb8320} AND Quarter=@{cb7e2046a0fba2204} AND Region='@{c5a93e65d31f10e01}' AND ItemType='@{c5a93e65d31f10e0}'</update>
         </writeBack>
      </XML>
   </WebMessage>
</WebMessageTable>
</WebMessageTables>

Note: You must include an <insert> element and an <update> element, even if both aren't used. For example, if you're only performing an insert, you must include the empty update statement <update></update>.

Copy the XML document containing your write-back templates to the clipboard.
Apply your write-back template in Oracle Analytics:
1. Go to Oracle Analytics.
2. , then click Console.
3. Click Advanced System Settings.
4. In Writeback Template XML, paste the write-back template that you copied in Step 3.
Grant permissions to use the write-back code:
1. Navigate to Classic home, then click Administration.
2. Under Security, click Manage Privileges, and navigate to Write Back.
3. Grant Write Back to Database to Authenticated User.
4. Grant Manage Write Back to BI Service Administrator.
To enable write-back in columns:
1. In the analysis editor, display the Column Properties of the column on which you want to enable write-back.
2. In the Column Properties dialog, click the Write Back tab.
  If the column has been enabled for write-back in the semantic model, then the Enable Write Back box is available.
3. Select the Enable Write Back option.
4. Specify the value of other options if you want to change the default.
5. Save your changes.
The column is enabled for write-back in any analysis that includes this column.
To enable write-back in table views:
1. In the analysis editor, open the table view for editing.
2. Click View Properties.
3. In the Table Properties dialog, click the Write Back tab.
4. Select the Enable Write Back option.
5. Select the Template Name box, specify the value of "WebMessage name=" in the write-back template that you specified in Step 2.
  For example, the Template Name for the example template in Step 2 is 'SetQuotaUseID'.
6. Save your changes.

Write-Back Limitations

Users can write back to any data source (except for an ADF data source) that allows the execution of SQL queries from Oracle BI Server.

As you configure for write back, keep the following limitations in mind:

Numeric columns must contain numbers only. They mustn't contain any data formatting characters such as dollar signs ($), pound signs or hash signs (#), percent signs (%), and so on.
Text columns must contain string data only.
If a logged-on user is already viewing a dashboard that contains an analysis where data has been modified using write back, the data isn't automatically refreshed in the dashboard. To see the updated data, the user must manually refresh the dashboard.
You can use the template mechanism only with table views and only for single-value data. The template mechanism isn't supported for pivot table views or any other type of view, for multiple-value data, or for drop down columns with single-value data.
All values in write-back columns are editable. When displayed in non printer friendly context, editable fields are displayed as if the user has the Write Back to Database privilege. However, when a logical column is mapped to a physical column that can change, the logical column returns values for multiple level intersections. This scenario might cause problems.
Any field in an analysis can be flagged as a write-back field, even if it's not derived from the write-back table that you created. However you can't successfully run the write-back operation if the table isn't write-back enabled. The responsibility for correctly tagging fields lies with the content designer.
A template can contain SQL statements other than insert and update. The write-back function passes these statements to the database. However, Oracle doesn't support or recommend the use of any statements other than insert or update.
Presentation Services performs only minimal validation of data input. If the field is numeric and the user enters text data, then Presentation Services detects that and prevents the invalid data from going to the database. However, it doesn't detect other forms of invalid data input (values out of range, mixed text and numeric, and so on). When the user clicks the write-back button and an insert or update is run, invalid data results in an error message from the database. The user can then correct the faulty input. Content designers can include text in the write-back analysis to aid the user, for example, "Entering mixed alphanumeric values into a numeric data field isn't allowed."
The template mechanism isn't suitable for entering arbitrary new records. In other words, don't use it as a data input tool.
When creating a table for write back, ensure that at least one column doesn't include write-back capability but does include values that are unique for each row and are non-null.
Write-back analyses don't support drill-down. Because drilling down modifies the table structure, the write-back template doesn't work.

Caution:
The template mechanism takes user input and writes it directly to the database. The security of the physical database is your own responsibility. For optimum security, store write-back database tables in a unique database instance.

Set the LightWriteback Element

For users to write back values, you must manually add the LightWriteback element in the instanceconfig.xml file.

Open the instanceconfig.xml file for editing, located in:

BI_DOMAIN/config/fmwconfig/biconfig/OBIPS
Locate the ServerInstance section in which you must add the LightWriteback element.
Include the element and its ancestor elements as appropriate, as shown in the following example:
```
<WebConfig>
    <ServerInstance>
        <LightWriteback>true</LightWriteback>
    </ServerInstance>
</WebConfig>
```
Note that this example doesn't include elements that might exist in the file, but that are centrally managed by Fusion Middleware Control and can't be changed manually.
Save your changes and close the file.
Restart the system.