Appboard/2.4/builder/widgets/actions/write static value: Difference between revisions

imported>Mike.berman
No edit summary
imported>Cmace
(action filtering based on data source, not data collection)
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{DISPLAYTITLE:AppBoard Action - Write Static Value}}
{{DISPLAYTITLE:Write Static Value}}
The "Write Static Value" Action provides users the ability to either perform updates that will be written back to a data source or use the current record to invoke an operation on the data source. When the client data model receives a DataObject change event, it will send the data to the server in an "Update" action request.
[[Category:AppBoard 2.4]]
The "Write Static Value" action provides a way to write a static value back to the data source based on the selected item. This action only works if the data source supports updates, and is configured appropriately if required.


A simple example and use of this action would be to set an acknowledged flag on a selected ticket in a table widget. In this case either a database table or query would be configured to retrieve the list of tickets, a widget configured to show the tickets, and the action created to set a specific field in order to mark it as acknowledged (e.g. the setting the "Acknowledged" field to "Yes"). See the example use case further down this page.


== Write changes back to a Data Source ==
As with any widget action it's possible to configure these in context, multiple actions if it's desired to set multiple fields, and action menus can be built if different operations need to be presented to the end-user.
An administrator may want to provide Users the ability to change the status of certain data elements.  For instance, changing the 'Acknowledged' flag in the data and write it back to the data source.  This is normally used for data backed by a database (excluding data returned by a stored procedure), or data backed by flat files (CSV, XLS).  For places where the data change will be converted to a web service request or API request, it is recommended to use the 'operation' syntax.




For instance, if you had the adapter for IBM Netcool/ObjectServer registered, you may want to be able to allow the user to acknowledge or unacknowledge an alert.  In this case, the administrator registers the "Write Static Value" Action on the alert data displayed in AppBoard.  When the Appboard Client DataModel receives the DataObject changed event, it will package the alert inside of an 'update' action request to the server.  The request will be delegated to the adapter, which will use the adapter configuration to create a connection to the data source (or pull from the data connection pool) and write the data back to the external system.
=== Supporting Data Source Types ===
 
{|class="wikitable"
 
!Data Source Type
This Action can also be used to enable the end-user to manually modify system status flags that are shared between users.
!Details
 
|-
 
|CSV file/dir
== Perform an Operation on a Data Source ==
|no configuration required on data source
 
|-
A data source adapter would specify what operations are supported. Normally this is used where an adapter is written against an API or Web Service, where you typically use the record as context information and the system uses that data to fill in the required properties of the request along with the data source's adapter configuration to establish a connection.
|Database Table
 
|automatic for entities with primary keys defined
 
|-
Operations are dependent on the support provided by a specific adapter.  For instance, an adapter may provide the ability to invoke the following operations on an event: 'acknowledge', 'unacknowledge', 'takeownership', and 'releaseownership'.  With these operations, you would typically define a menu of operations to act on a type of data.
|Database Query
|each entity (query) needs a specific SQL update statement defined
|}




Line 36: Line 39:
### Click <b>Add Rule</b> to create one or more rules that indicate what data should trigger the Action, when selected.
### Click <b>Add Rule</b> to create one or more rules that indicate what data should trigger the Action, when selected.
### Click <b>Close</b> to save the Filter settings.
### Click <b>Close</b> to save the Filter settings.
## Select the Data Collection name. When the Widget is run, selection of data in this Data Collection will trigger the Action.  
## Select the Data Source name. When the Widget is run, selection of data in this Data Source will trigger the Action.  
# Enter the following information:
# Enter the following information:
## <b>Field Name</b>: Select the name of the field for the user-selected record that AppBoard will update.
## <b>Field Name</b>: Select the name of the field for the user-selected record that AppBoard will update.
Line 44: Line 47:
== Sample Use Case ==
== Sample Use Case ==


Suppose a Table Widget displays data from the following source to a User:
Suppose ticket data is retrieved via a database query to a ticketing system. The query could be something like this:
 
<pre>
select TicketID, CustomerID, `IP Address`, Error, Acknowledged from TicketTable
</pre>


And the '''raw''' data returned from the query:


{| class="wikitable" border="1" style="background-color:#eeeeee;"
{|class="wikitable"
|+ align="bottom" style="color:#e76700;" |''Raw Error Acknowledgement Data on Server''
|-
|-
! width=150 | Customer ID
! TicketID
! width=150 | IP Address
! CustomerID
! width=150 | Error
! IP Address
! width=150 | Acknowledged
! Error
! Acknowledged
|-
|-
| 41211
| 0001
| 0001
| 172.21.38.220
| 172.21.38.220
Line 60: Line 69:
| No
| No
|-
|-
| 41212
| 0001
| 0001
| 172.21.38.226
| 172.21.38.226
Line 65: Line 75:
| No
| No
|-
|-
| 41213
| 0002
| 0002
| 172.26.11.101
| 172.26.11.101
Line 70: Line 81:
| No
| No
|-
|-
| style="background-color:#3BB9FF"|0002
| 41214
| style="background-color:#3BB9FF"|172.21.38.105
| 0002
| style="background-color:#3BB9FF"|License Warning
| 172.21.38.105
| style="background-color:#3BB9FF"|Yes
| License Warning
| ''Yes''
|-
|-
| style="background-color:#3BB9FF"|0002
| 41215
| style="background-color:#3BB9FF"|172.21.38.313
| 0002
| style="background-color:#3BB9FF"|Temperature too high
| 172.21.38.313
| style="background-color:#3BB9FF"|Yes
| Temperature too high
| ''Yes''
|}
|}




The Table Widget's Data Collection has a Client Side filter that only displays errors that have not been acknowledged (Acknowledged="No"). So the Table Widget displays the following data:
Within AppBoard the administrator creates a Table widget driven by this data but also configures a client side filter to filter out rows that have already been acknowledged, saving the end-user some time by only showing the outstanding tickets. Therefore the sub-set of tickets the end-user sees would be:
 


{| class="wikitable" border="1" style="background-color:#eeeeee;"
{| class="wikitable"
|+ align="bottom" style="color:#e76700;" |''Filtered Error Acknowledgement Data in Table Widget''
|-
|-
! width=150 | Customer ID
! TicketID
! width=150 | IP Address
! CustomerID
! width=150 | Error
! IP Address
! width=150 | Acknowledged
! Error
! Acknowledged
|-
|-
| 41211
| 0001
| 0001
| 172.21.38.220
| 172.21.38.220
Line 98: Line 111:
| No
| No
|-
|-
| 41212
| 0001
| 0001
| 172.21.38.226
| 172.21.38.226
Line 103: Line 117:
| No
| No
|-
|-
| 41213
| 0002
| 0002
| 172.26.11.101
| 172.26.11.101
Line 110: Line 125:




Suppose that when the User clicks on a row, he acknowledges the error and it should then be removed from the display. To do this, you can create a "Write Static Value" Action that will write the Value "Yes" to the Field "Acknowledged".
Finally, the administrator configures a Write Static Value on the table widget and sets the Field Name to '''Acknowledged''' and the Value to "Yes". When this happens the field is updated back to the database and all end-users will no longer see the ticket on next data collection refresh as it will be filtered by the client side filter.
 
In order for this to work it would also be necessary to configure an Update Statement on the database query. Note the '':fieldName'' is substituted by the fields from the selected row or the static value of the action if that particular field is the configured '''Field Name'''.
 
<pre>update TicketTable set Acknowledged=:Acknowledged where TicketID=:TicketID</pre>

Latest revision as of 18:53, 1 May 2014

The "Write Static Value" action provides a way to write a static value back to the data source based on the selected item. This action only works if the data source supports updates, and is configured appropriately if required.

A simple example and use of this action would be to set an acknowledged flag on a selected ticket in a table widget. In this case either a database table or query would be configured to retrieve the list of tickets, a widget configured to show the tickets, and the action created to set a specific field in order to mark it as acknowledged (e.g. the setting the "Acknowledged" field to "Yes"). See the example use case further down this page.

As with any widget action it's possible to configure these in context, multiple actions if it's desired to set multiple fields, and action menus can be built if different operations need to be presented to the end-user.


Supporting Data Source Types

Data Source Type Details
CSV file/dir no configuration required on data source
Database Table automatic for entities with primary keys defined
Database Query each entity (query) needs a specific SQL update statement defined


How To Create a Write Static Value Action

For instructions on adding an Action to a Widget, see the general instructions in How To Create an Action in a Widget.


How To Configure a Write Static Value Action

Perform the following steps to configure the "Write Static Value" Action for a Widget:

  1. Follow the instructions above to create the Action in the Widget Actions panel.
  2. Name: Enter a name for this Action. For convenience, a default name is provided. The Name is not used anywhere else in AppBoard, and only displayed on this configuration page.
  3. On selection of:
    1. Select "any" or "specific" for the type of data selection by the User that will trigger the Action. When selecting "specific", perform the following additional steps:
      1. Click the Filter button. The Filter Editor is displayed.
      2. Click Add Rule to create one or more rules that indicate what data should trigger the Action, when selected.
      3. Click Close to save the Filter settings.
    2. Select the Data Source name. When the Widget is run, selection of data in this Data Source will trigger the Action.
  4. Enter the following information:
    1. Field Name: Select the name of the field for the user-selected record that AppBoard will update.
    2. Value: Enter the value that AppBoard will write for the indicated field in the user-selected record.


Sample Use Case

Suppose ticket data is retrieved via a database query to a ticketing system. The query could be something like this:

select TicketID, CustomerID, `IP Address`, Error, Acknowledged from TicketTable

And the raw data returned from the query:

TicketID CustomerID IP Address Error Acknowledged
41211 0001 172.21.38.220 License Expired No
41212 0001 172.21.38.226 Server Not Responding No
41213 0002 172.26.11.101 Slow response time No
41214 0002 172.21.38.105 License Warning Yes
41215 0002 172.21.38.313 Temperature too high Yes


Within AppBoard the administrator creates a Table widget driven by this data but also configures a client side filter to filter out rows that have already been acknowledged, saving the end-user some time by only showing the outstanding tickets. Therefore the sub-set of tickets the end-user sees would be:

TicketID CustomerID IP Address Error Acknowledged
41211 0001 172.21.38.220 License Expired No
41212 0001 172.21.38.226 Server Not Responding No
41213 0002 172.26.11.101 Slow response time No


Finally, the administrator configures a Write Static Value on the table widget and sets the Field Name to Acknowledged and the Value to "Yes". When this happens the field is updated back to the database and all end-users will no longer see the ticket on next data collection refresh as it will be filtered by the client side filter.

In order for this to work it would also be necessary to configure an Update Statement on the database query. Note the :fieldName is substituted by the fields from the selected row or the static value of the action if that particular field is the configured Field Name.

update TicketTable set Acknowledged=:Acknowledged where TicketID=:TicketID