Use Cases
Use cases for signed embed
Case: Utilizing Embedded Dashboards in Retail Support SaaS
Scenario
In a SaaS platform that supports retail store operations, we assume a need to embed dashboards within the SaaS to understand sales performance and KPIs for each store. This functionality allows store managers and area managers to view only information related to their stores when they log in.
Notebook Parameters
The notebook that serves as the source for signed embed is assumed to have the following parameters configured:
tenant_id:Tenant ID to which the logged-in user belongs
"Text input" type parameter
store_id:Store ID for which data is to be displayed
"Text select" type parameter, where options allow selection of store IDs within the tenant specified by
tenant_id
date_range:Data aggregation period
"Date range" type parameter with a default value of relative dates spanning 7 days from the previous day
product_category:Product category for narrowing down data aggregation targets
"Text multi select" type parameter, with SQL conditions specified to display all product categories when none are selected
Configuration Example A: Using Signed Embed Forms
Prerequisite Notebook Design
Security of data accessible to users is ensured by fixing
tenant_idSQL for data extraction always specifies
tenant_idas a filter conditionFor example, when extracting store data, both
store_idandtenant_idare specified as filter conditions, preventing extraction of data from stores belonging to different tenants
date_rangeandproduct_categoryare designed to allow arbitrary values
Parameter Configuration
tenant_id: Fixed value for a server-side parameterstore_id: Initial value for a server-side parameterdate_range: Client-side parameterproduct_category: Client-side parameter
Flow to Display
Token issuance on server-side
Specify the user's
tenant_idas a fixed value for a server-side parameterSpecify the
store_idto display in the initial state as an initial value for a server-side parameter, selected from among thestore_idvalues associated withtenant_id
Initial rendering process on front-end
When sending the
SET_TOKENmessage, send the following client-side parameters together:date_rangeis specified to reset to default value for relative date recalculationproduct_categoryis specified with an empty array as the initial value
User dashboard operations
Users can change
store_id,date_range, andproduct_categoryfrom the dashboard form
Configuration Example B: Managing Parameters on SaaS Front-end
Prerequisite Notebook Design
The same design as "Configuration Example A"
Parameter Configuration
tenant_id: Fixed value for a server-side parameterstore_id: Client-side parameterdate_range: Client-side parameterproduct_category: Client-side parameter
Flow to Display
Token issuance on server-side
Specify the user's
tenant_idas a fixed value for a server-side parameter
Initial rendering process on front-end
When sending the
SET_TOKENmessage, send the following client-side options together:Since parameters are managed on the SaaS side, specify the option to hide the parameter form (
displayOptions.hideParamsForm = true)Specify values managed on the SaaS side for
store_id,date_range, andproduct_category
User dashboard operations
When changing dashboard display conditions due to changes in conditions managed on the SaaS side, follow these steps:
Reuse the token used in the initial rendering process and resend the
SET_TOKENmessage with updated client-side optionsBy resending the
SET_TOKENmessage, the dashboard is redrawn based on the newly sent client-side optionsThe client-side parameters sent at this time must include all items (
store_id,date_range,product_category), not just the differencesWhen the same user uses the same fixed value for a server-side parameter, token reuse is possible (note the expiration time)
Configuration Example C: Updating Server-side Fixed Values
Prerequisite Notebook Design
Security of data accessible to users is ensured by fixing both
tenant_idandstore_idUnlike "Configuration Example A", this assumes a case where
store_idneeds to be fixed on the server-side
date_rangeandproduct_categoryare designed to allow arbitrary values, same as "Configuration Example A"
Parameter Configuration
tenant_id: Fixed value for a server-side parameterstore_id: Fixed value for a server-side parameterdate_range: Client-side parameterproduct_category: Client-side parameter
Flow to Display
Token issuance on server-side
Specify the user's
tenant_idand thestore_idto display in the initial state as fixed values for server-side parameters
Initial rendering process on front-end
When sending the
SET_TOKENmessage, send the following client-side parameters together:date_rangeis specified to reset to default value for relative date recalculationproduct_categoryis specified with an empty array as the initial value
User dashboard operations
Since
store_idis a fixed value for a server-side parameter, it cannot be changed from the dashboard form, and the SaaS side needs to managestore_idand provide a form for changing the target storeWhen redrawing the dashboard by changing
store_idbased on user operations, follow these steps:Issue a new token to the server-side specifying the new
store_id, and send theSET_TOKENmessage with the new token and client-side parametersTo change fixed values for server-side parameters, token reissuance is required
Client-side parameters must include all items (
date_range,product_category), not just the differencesTo preserve
date_rangeorproduct_categorychanged by user operations, record thePARAM_CHANGEDmessages sent from the iframe and send them during redrawing
For
date_rangeandproduct_category, users can change the display content from the dashboard form
Last updated
Was this helpful?

