Appboard/2.4/builder/widgets/actions/write static value - Revision history

imported>Cmace: action filtering based on data source, not data collection

2014-05-01T18:53:39Z

action filtering based on data source, not data collection

← Older revision		Revision as of 18:53, 1 May 2014
Line 39:		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.

imported>Jason.nicholls at 09:04, 14 December 2013

2013-12-14T09:04:11Z

← Older revision		Revision as of 09:04, 14 December 2013
Line 1:		Line 1:
	{{DISPLAYTITLE:~~AppBoard Action -~~ Write Static Value}}		{{DISPLAYTITLE:Write Static Value}}
			[[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.		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.

imported>Jason.nicholls: /* Sample Use Case */

2013-09-18T03:23:16Z

Sample Use Case

← Older revision		Revision as of 03:23, 18 September 2013
Line 123:		Line 123:
	\|}		\|}

	Finally, the administrator configures a Write Static Value on the table widget to ~~set~~ the ~~Acknowledged field~~ 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.
			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'''.		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>		<pre>update TicketTable set Acknowledged=:Acknowledged where TicketID=:TicketID</pre>

imported>Jason.nicholls: /* Sample Use Case */

2013-09-18T03:21:40Z

Sample Use Case

← Older revision		Revision as of 03:21, 18 September 2013
Line 46:		Line 46:
	== Sample Use Case ==		== Sample Use Case ==

	Suppose ~~the following ''raw''~~ ticket data is retrieved via a database query to a ticketing system:		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"		{\|class="wikitable"
	\|-		\|-
	! ~~Ticket ID~~		! TicketID
	! ~~Customer ID~~		! CustomerID
	! IP Address		! IP Address
	! Error		! Error
Line 74:		Line 80:
	\| No		\| No
	\|-		\|-
	~~\| style="background-color:#3BB9FF"~~\|41214		\| 41214
	~~\| style="background-color:#3BB9FF"~~\|0002		\| 0002
	~~\| style="background-color:#3BB9FF"~~\|172.21.38.105		\| 172.21.38.105
	~~\| style="background-color:#3BB9FF"~~\|License Warning		\| License Warning
	\| ~~style="background-color:#3BB9FF"\|~~Yes		\| ''Yes''
	\|-		\|-
	~~\| style="background-color:#3BB9FF"~~\|41215		\| 41215
	~~\| style="background-color:#3BB9FF"~~\|0002		\| 0002
	~~\| style="background-color:#3BB9FF"~~\|172.21.38.313		\| 172.21.38.313
	~~\| style="background-color:#3BB9FF"~~\|Temperature too high		\| Temperature too high
	\| ~~style="background-color:#3BB9FF"\|~~Yes		\| ''Yes''
	\|}		\|}

Line 92:		Line 98:
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
	! ~~Ticket ID~~		! TicketID
	! ~~Customer ID~~		! CustomerID
	! IP Address		! IP Address
	! Error		! Error
Line 117:		Line 123:
	\|}		\|}

			Finally, the administrator configures a Write Static Value on the table widget to set the Acknowledged field 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'''.

	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".		<pre>update TicketTable set Acknowledged=:Acknowledged where TicketID=:TicketID</pre>

imported>Jason.nicholls: /* Sample Use Case */

2013-09-18T03:13:27Z

Sample Use Case

← Older revision		Revision as of 03:13, 18 September 2013
Line 46:		Line 46:
	== Sample Use Case ==		== Sample Use Case ==

	Suppose ~~a Table Widget displays data from~~ the following ~~source~~ to a ~~User~~:		Suppose the following ''raw'' ticket data is retrieved via a database query to a ticketing system:


	{\|class="wikitable"		{\|class="wikitable"
	~~\|+ align="bottom" style="color:#e76700;" \|''Raw Error Acknowledgement Data on Server''~~
	\|-		\|-
	! ~~width=150 \|~~ Customer ID		! Ticket ID
	! ~~width=150 \|~~ IP Address		! Customer ID
	! ~~width=150 \|~~ Error		! IP Address
	! ~~width=150 \|~~ Acknowledged		! Error
			! Acknowledged
	\|-		\|-
			\| 41211
	\| 0001		\| 0001
	\| 172.21.38.220		\| 172.21.38.220
Line 62:		Line 62:
	\| No		\| No
	\|-		\|-
			\| 41212
	\| 0001		\| 0001
	\| 172.21.38.226		\| 172.21.38.226
Line 67:		Line 68:
	\| No		\| No
	\|-		\|-
			\| 41213
	\| 0002		\| 0002
	\| 172.26.11.101		\| 172.26.11.101
Line 72:		Line 74:
	\| No		\| No
	\|-		\|-
			\| style="background-color:#3BB9FF"\|41214
	\| style="background-color:#3BB9FF"\|0002		\| style="background-color:#3BB9FF"\|0002
	\| style="background-color:#3BB9FF"\|172.21.38.105		\| style="background-color:#3BB9FF"\|172.21.38.105
Line 77:		Line 80:
	\| style="background-color:#3BB9FF"\|Yes		\| style="background-color:#3BB9FF"\|Yes
	\|-		\|-
			\| style="background-color:#3BB9FF"\|41215
	\| style="background-color:#3BB9FF"\|0002		\| style="background-color:#3BB9FF"\|0002
	\| style="background-color:#3BB9FF"\|172.21.38.313		\| style="background-color:#3BB9FF"\|172.21.38.313
Line 84:		Line 88:


	~~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"		{\| class="wikitable"
	~~\|+ align="bottom" style="color:#e76700;" \|''Filtered Error Acknowledgement Data in Table Widget''~~
	\|-		\|-
	! ~~width=150 \|~~ Customer ID		! Ticket ID
	! ~~width=150 \|~~ IP Address		! Customer ID
	! ~~width=150 \|~~ Error		! IP Address
	! ~~width=150 \|~~ Acknowledged		! Error
			! Acknowledged
	\|-		\|-
			\| 41211
	\| 0001		\| 0001
	\| 172.21.38.220		\| 172.21.38.220
Line 100:		Line 104:
	\| No		\| No
	\|-		\|-
			\| 41212
	\| 0001		\| 0001
	\| 172.21.38.226		\| 172.21.38.226
Line 105:		Line 110:
	\| No		\| No
	\|-		\|-
			\| 41213
	\| 0002		\| 0002
	\| 172.26.11.101		\| 172.26.11.101

imported>Jason.nicholls at 03:06, 18 September 2013

2013-09-18T03:06:21Z

← Older revision		Revision as of 03:06, 18 September 2013
Line 2:		Line 2:
	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.		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 "~~ack~~" field to "1").		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.		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.

imported>Jason.nicholls at 03:05, 18 September 2013

2013-09-18T03:05:07Z

← Older revision		Revision as of 03:05, 18 September 2013
Line 1:		Line 1:
	{{DISPLAYTITLE:AppBoard Action - Write Static Value}}		{{DISPLAYTITLE:AppBoard Action - Write Static Value}}
	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.		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 "ack" field to "1").

			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.


Line 17:		Line 21:
	\|each entity (query) needs a specific SQL update statement defined		\|each entity (query) needs a specific SQL update statement defined
	\|}		\|}


	~~== Write changes back to a Data Source ==~~
	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.


	~~This Action can also be used to enable the end-user to manually modify system status flags that are shared between users.~~


	~~== Perform an Operation on a 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.


	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.


Line 63:		Line 49:


	{\| class="wikitable~~" border="1" style="background-color:#eeeeee;~~"		{\|class="wikitable"
	\|+ align="bottom" style="color:#e76700;" \|''Raw Error Acknowledgement Data on Server''		\|+ align="bottom" style="color:#e76700;" \|''Raw Error Acknowledgement Data on Server''
	\|-		\|-
Line 101:		Line 87:


	{\| class="wikitable~~" border="1" style="background-color:#eeeeee;~~"		{\| class="wikitable"
	\|+ align="bottom" style="color:#e76700;" \|''Filtered Error Acknowledgement Data in Table Widget''		\|+ align="bottom" style="color:#e76700;" \|''Filtered Error Acknowledgement Data in Table Widget''
	\|-		\|-

imported>Jason.nicholls at 02:55, 18 September 2013

2013-09-18T02:55:53Z

← Older revision		Revision as of 02:55, 18 September 2013
Line 1:		Line 1:
	{{DISPLAYTITLE:AppBoard Action - Write Static Value}}		{{DISPLAYTITLE:AppBoard Action - 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.~~		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.


			=== Supporting Data Source Types ===
			{\|class="wikitable"
			!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
			\|}

imported>Mike.berman at 00:51, 5 September 2013

2013-09-05T00:51:48Z

← Older revision		Revision as of 00:51, 5 September 2013
Line 27:		Line 27:

	== How To Configure a Write Static Value Action ==		== How To Configure a Write Static Value Action ==
			Perform the following steps to configure the "Write Static Value" Action for a Widget:

	# Follow the instructions above to create the Action in the <b>Widget Actions</b> panel.		# Follow the instructions above to create the Action in the <b>Widget Actions</b> panel.

imported>Mike.berman: create page for AppBoard 2.4

2013-09-05T00:14:12Z

create page for AppBoard 2.4

New page

{{DISPLAYTITLE:AppBoard Action - 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.

== Write changes back to a Data Source ==
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.

This Action can also be used to enable the end-user to manually modify system status flags that are shared between users.

== Perform an Operation on a 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.

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.

== How To Create a Write Static Value Action ==

For instructions on adding an Action to a Widget, see the general instructions in [[appboard/2.4/builder/widgets/actions#How_To_Create_an_Action_in_a_Widget|How To Create an Action in a Widget]].

== How To Configure a Write Static Value Action ==

# Follow the instructions above to create the Action in the Widget Actions panel.
# 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.
# On selection of:
## 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:
### Click the Filter button. The Filter Editor is displayed.
### Click Add Rule to create one or more rules that indicate what data should trigger the Action, when selected.
### Click Close 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.
# Enter the following information:
## Field Name: Select the name of the field for the user-selected record that AppBoard will update.
## Value: Enter the value that AppBoard will write for the indicated field in the user-selected record.

== Sample Use Case ==

Suppose a Table Widget displays data from the following source to a User:

{| class="wikitable" border="1" style="background-color:#eeeeee;"
|+ align="bottom" style="color:#e76700;" |''Raw Error Acknowledgement Data on Server''
|-
! width=150 | Customer ID
! width=150 | IP Address
! width=150 | Error
! width=150 | Acknowledged
|-
| 0001
| 172.21.38.220
| License Expired
| No
|-
| 0001
| 172.21.38.226
| Server Not Responding
| No
|-
| 0002
| 172.26.11.101
| Slow response time
| No
|-
| style="background-color:#3BB9FF"|0002
| style="background-color:#3BB9FF"|172.21.38.105
| style="background-color:#3BB9FF"|License Warning
| style="background-color:#3BB9FF"|Yes
|-
| style="background-color:#3BB9FF"|0002
| style="background-color:#3BB9FF"|172.21.38.313
| style="background-color:#3BB9FF"|Temperature too high
| style="background-color:#3BB9FF"|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:

{| class="wikitable" border="1" style="background-color:#eeeeee;"
|+ align="bottom" style="color:#e76700;" |''Filtered Error Acknowledgement Data in Table Widget''
|-
! width=150 | Customer ID
! width=150 | IP Address
! width=150 | Error
! width=150 | Acknowledged
|-
| 0001
| 172.21.38.220
| License Expired
| No
|-
| 0001
| 172.21.38.226
| Server Not Responding
| No
|-
| 0002
| 172.26.11.101
| Slow response time
| No
|}

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".