Demo and Trial Accounts Setup
- Sylvain Paillard
We need to scale up and manage to reach a point we can easily manage 10-20 new demos or trial accounts per month. In that logic, we need to have an optimized process which is as automated as possible.
Data Input:
Demos:
list of demo accounts is provided by
bx-bdp-53322.external_intelligence_views.demos_accounts
For Each account, the following views provide the required data for content and product update:
doc_product
doc_attribute (for products)
doc_attribute_value (for products)
doc_language (for both)
doc_content
data are to provided only in prod (no dev) and only in full (no delta or instant)
If it is not ideal, we can move the dataform setup in another dataform repo. It is just more convenient to have it there as the external-intelligence is where we do the preparation of the demo data. The idea of the setup is currently that it uses the account name set in dataform vars.client and execute the “demo” tag which simply ovewrite the views in bx-bdp-53322.external_intelligence_views.demos_*** ) with *** being (doc_product, doc_attribute, …).
if needed, the setup can be changed to make the process more automatable.
Trials:
Product data come from E-Commerce system (e.g.: Shopify for dancing queens)
Content Data come from Prismic which requires the following initialization:
Content and Structure of reference demo account (currently PKZ, but subject to change)
It would be better to have a reference demo account (at least for prismic) which we can edit as we want and which is used to initialize (or overwrite) demo or trial accounts automatically
Optional: Google Analytics, Google Ads and Google Merchant Center Data transfer (will require manual configuration of connection in project dataform )
Account Setup:
Demos:
It is not required that the Demos have their own GCP project (win-p-…), however, we must be able to very easily ‘migrate’ a demo to become a trial (as this is the goal of the demo, to motivate a new customer to do a trial). Therefore the migration from a demo setup to a trial setup needs to be efficient and as automated as possible. Such migration will also imply a migration of the data inputs (as per the section before).
The setup must allow for the executions of the workflows described in the following sections which are the same for Demos and Trials.
Trials:
win-p-Client project with dataform (and other standard setups) + All the requirements of the Demos executions.
Workflows:
The following workflows need to be executed successfully in this order:
1 : ‘Dry run’ of the Product Full and Content Full
First, we need to do an initial successful load of all the solrsync resources including the full product and content data successfully.
This should include all the dependencies for the search (corpus, autocomplete, properties)
2 : WI-Analytics-Standard
Successful one-time WI-Analytics-Standard of the account
(which requires that the demo accounts all of the _core, _views, _reports, _lab, _intelligence dataset initialized)
first with the tag : ‘full’
and after with the tag ‘config’
3 : Intelligence Admin Creation + Credentials creation
The intelligence admin account needs to be created and the following API credentials need to be created and deployed for the following ROLES
CORE
PUBLIC_NARRATIVE
ADMIN
PUBLIC_CHAT*
* CHAT : So far, Simon did it manually once for renovero and for geschenkidee. INSERT INTO authentry(apikey,apisecret,roles,solrindexpatterns,username) VALUES('377d656f-a3f0-44d3-9769-59a8ecce2bc7', null, '["PUBLIC_CHAT"]', '["renovero_api_*"]', 'renovero_api');
We need to discuss how we want to do it, because it is not supported by the admin GUI, but I think it will work if it is loaded by api directly
As soon as possible, I would like to shift away from using the intelligence admin for Credentials management and rely on the GCP / admin.bx-cloud.com systems to manage the credentials and remove the dependency to the old admin for api key management (to discuss when it is the right moment to migrate this aspect for the demos / trials)
4 : Intelligence Admin Config
The execution of the ‘config’ tag of WI-Analytics-Standard will generate the following view
bx-bdp-53322.lehner_versand_views.config_upload
As we did for SwissCommerce, we need to have a service which automatically loads the configuration in the admin server:
/broadcast/319f55bb-33d4-4334-b90b-a347b41e3af3?dataFeedView=_config
5 : Embeddings & Blurhash creations
The following services must be called and executed until they don’t do anything with the account as parameter (which is not supported yet and should be added):
bx-bdp-53322.boxalino_views.input_data_feeds_openai_embeddings
bx-bdp-53322.boxalino_views.input_data_feeds_openai_embeddings_content
bx-bdp-53322.boxalino_views.input_data_feeds_openai_embeddings_topics
bx-bdp-53322.boxalino_views.input_data_feeds_blurhash
This current setup is far from being optimal and is a major cost generator (as we have seen for the rtux-data-integration for mooris_api) and also doesn’t garantee that the embeddings and the blurhash are always done in time when new produts are added in a delta. Therefore, it might be relevant to directly improve this flow and make it a fully integrated part of the Product and Content execution (in rtux-data-integration). Because if we do this properly, then this workflow can be fully skipped as it will not be needed anymore
6: ‘Real’ run of the Product Full and Content Full
A new run of the product full and content full is required as additional fields will have been created by the step 2-5 and the content and product data needs to be updated with them.
7: Automated testing of the Narrative API requests and of the Chat API requests
We need to automatically test the functioning of the Narrative API for cases of the widgets
search
basket
and of the chat
to verify they work and to provide them as sample requests to the flutter development team
I am not sure what is the best way to do that, to be discussed