• Adding comments to dashboards.
• Users managing tables (pricing, etc.).
• Audit applications.
• Feedback forms.

How can this be accomplished with Looker?
By using Actions by Looker.

What should you be familiar with?                                

• Python (or NodeJS)
• LookML

What should you have?

• Permissions to manage Google Cloud Functions in your GCP.
• Looker Dev Access

Have them all? Let’s get started.

Example use case:

Consider the following table:

actions_ad_data

Users should be able to update the information/add comments in this table directly from Looker dashboards. This article walks you through the process of achieving that functionality.

As a part of that, to catch all the entered comments, a new table has to be created on the database, similar to this one:

actions_comments

And on Looker, create a view on the comments table, and join it with the initial ad_data explore, as follows:

view: actions_comments {
  sql_table_name: !@#$%^&*.actions_comments ;;
  dimension: ad_id {
    type: number
    sql: ${TABLE}.ad_id ;;
  }
  dimension: comment {
    type: string
    sql: ${TABLE}.comment ;;
  }
  dimension: p_key {
    type: string
    primary_key: yes
    sql: ${ad_id}|| '' || ${time_raw} ;;
  }
  dimension_group: time {
    type: time
    timeframes: [
      raw,
      time,
      date,
      week,
      month,
      quarter,
      year
    ]
    sql: ${TABLE}.time ;;
  }
  dimension: u_name {
    type: string
    sql: ${TABLE}.u_name ;;
  }
  measure: count {
    type: count
    drill_fields: [u_name]
  }
}

connection: "!@#$%^&*"
include: "*.view.lkml"
explore: actions_ad_data {
  label: "Ad Data"
  description: "Created just to try Data Actions."
join: actions_comments {
  sql_on: ${actions_ad_data_dt.ad_id} = ${actions_comments.ad_id} ;;
  relationship: one_to_many
  type: left_outer
}
}

Before moving on with actual implementation, here is a high-level illustration of the entire writeback process using Data Actions:
Within a Looker Action, all the parameters and forms are bundled together as a JSON. And when a cloud function is triggered by that action, that cloud function collects the bundled information from Looker, validates it and posts the data onto the database according to the given instructions. Make sure to give those instructions good and accurate.

Now, assuming that all of the important visualizations will be including the actions_ad_data.ad_id, two data actions were added to that dimension, as follows:

view: actions_ad_data {
  sql_table_name: !@#$%^&*.actions_ad_data ;;
.
.
.
dimension: ad_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.ad_id ;;

   action: {
      label: "Update Money Spent"
      url: "https://!@#$%^&*.cloudfunctions.net/changeamount_actions"
     param: {
        name:"id"
        value: "{{value}}"
      }
     form_param: {
        name: "changeamount"
        type: string
        label: "Amount"
        description: "Enter new amount above."
        required: yes
      }
    }


   action: {
      label: "Add comment"
      url: "https://!@#$%^&*.cloudfunctions.net/changeamount_comments"
     param: {
        name:"id"
        value: "{{value}}"
      }
     user_attribute_param: {
        user_attribute: user_attribute_name
        name: "username"
      }
     form_param: {
        name: "comment"
        type: textarea
        label: "Enter the comment"
        required: yes
      }
    }
  }
.
.
.
}

The two actions are “Update Money Spent” and “Add comment”. They are almost the same but understand that the target URLs are different, targeting a cloud function relevant to the action. Here are the cloud functions that are up and running on the Google Cloud:
Here is “changeamount_actions” function configuration:

Note: Don’t forget to mention ‘google-cloud-bigquery==1.5.0’ in requirements.txt of each cloud functions. Also, this function can be done using NodeJS as well.

And it’s source code:

from google.cloud import bigquery     # DO NOT FORGET THIS
import datetime
import time

def changeamount(request):
r = request.get_json() # Fetch the data action JSON

client = bigquery.Client()
dataset_id = '!@#$%^&*' # Replace with name of your BQ dataset
table_id = 'actions_ad_data'  # replace with your table ID
table_ref = client.dataset(dataset_id).table(table_id)
table = client.get_table(table_ref)

# getting the data
id = r['data']['id']
amount = r['form_params']['changeamount']
sys_time = int(time.time())

row_to_update = [
(
id,
amount,
datetime.datetime.fromtimestamp(sys_time).strftime('%Y-%m-%d %H:%M:%S')
)
]

row = client.insert_rows(table, row_to_update)  # API request to insert row
return '{"looker": {"success": true,"refresh_query": true}}' # return success response to Looker forcing it to refresh

[/vc_column_text][vc_column_text css=”.vc_custom_1541804171616{margin-bottom: 0px !important;}”]The other Cloud Function’s configuration is similar to the first one, and so here is the source code of it:

from google.cloud import bigquery
import datetime
import time

def addcomment(request):
r = request.get_json() # Fetch the data action JSON

client = bigquery.Client()
dataset_id = 'learning' # Replace with name of the BQ dataset 
table_id = 'actions_comments' # replace with your table ID
table_ref = client.dataset(dataset_id).table(table_id)
table = client.get_table(table_ref) # API request

# request variables
id = r['data']['id']
u_name = r['data']['username']
comment = r['form_params']['comment']
sys_time = int(time.time())

row_to_update = [
(
comment,
u_name,
datetime.datetime.fromtimestamp(sys_time).strftime('%Y-%m-%d %H:%M:%S'),
id
)
]
row = client.insert_rows(table, row_to_update) # API request to insert row
return '{"looker": {"success": true,"refresh_query": true}}' # return success response to Looker

Breaking down the code:

Take a look at the “Update Money Spent” action declaration in actions_ad_data.

Within that action, param and form_param contain the data that might be required to be sent to the server (which in this case is the Cloud Function). Read about param and form_param in this link.

The second action is “Add comment”, which is similar to the first one, but with a new user_attribute_param, which just contains the user attributes, and in this case the full name of currently logged in user. This can also be achieved by using ‘liquid’.

Now, on the cloud function, the dataset_id and table_id onto which the data is to be written is hard-coded into specific variables. And also, the function tries to retrieve data from the JSON, store it within appropriate variables and then tries inserting all the variables together onto the table as a new row.

Here is a video of Data Actions on an example dashboard created on the example data:

Remember:

#1

BigQuery is append-only. So, new rows will be added, instead of updating existing rows. Here is one way to avoid showing duplicates on Looker:

• Make sure the table have timestamps.
• Create a PDT to retrieve the latest information of each pkey, and set a sql_trigger on the timestamp field.

#2

Do not share the Cloud Function’s URL. Anyone with the URL can write data to your BigQuery instance. Try adding some checks/validation that the request is coming from Looker.

#3

Make sure the end-user knows where the data actions are, and how they’re supposed to be used.

Other Useful links:

Joins in Looker: https://docs.looker.com/data-modeling/learning-lookml/working-with-joins

About Datagroups: https://docs.looker.com/reference/model-params/datagroup

Another example: https://discourse.looker.com/t/update-write-back-data-on-bigquery-from-looks/9408/2

This blog was developed in collaboration with Looker’s Customer Success Engineer Jesse Carah.

• Global information technology spending to reach $3.7 trillion in 2018 (Source: Zdnet).
• The most significant increase in information technology spending to be on predictive analytics (Source: IDG).
• 79% of UK chief information officers expected to invest in data analytics in 2018 and 2019 (Source: CIO).

Imagine this scenario. You are a start-up business in the fintech sector and have recently acquired a glut of new customers, who all have different demands and expectations. At the moment, they are all represented in a simple SQL database which requires root access. It is messy and inefficient to find any single customer. What you need is a data visualization solution.

If you visualize each customer’s data effectively, you will be able to explain it to your employees more easily and intuitively. They will be able to act on it with the knowledge required to use it appropriately, and inexperienced employees will waste no time trying to understand how to access the database.

Data visualization can also help to show you new patterns which you might previously have missed. When presented in novel visual forms, it is easier to spot different trends which could lead to new approaches to your business strategy in a particular area. It could also help you to solve existing problems which you might have been thinking about in a specific, narrow way because of the way in which the data appears.

Data visualization offers plenty of opportunities for innovation in business practices. Perhaps the most important of these is in changing the way data is processed by your employees. It can speed up business processes and suggest new ways of running departments and organizing employees. It is the final frontier in understanding your customer’s consumption patterns.

1. Under “1. Allowed Senders” one of the three options can be selected.
2. Under “2. Authentication”, check “Only accept mail from the specified IP addresses:” and provide the IP address of the MicroStrategy I-Server.
3. “Require TLS encryption:” should be UNCHECKED as MicroStrategy does not support this feature at this time.

After the above steps are completed, under MicroStrategy “Administration > Devices” a new device can be created or existing device can be modified to use “Smart Host”.

1. IP Address / Server Name should be “smtp-relay.gmail.com”
2. Port number should be set to 25.
3. “Always use smart host” should be checked.
4. Under “Transmitters” edit “Email” to change the “From” and “Reply-to” email addresses. Both should be from the same domain where SMTP reply service is configured. Based on the above example it should be “mymstr.com”

The above device that is created/modified should be used when configuring new email addresses. This will let MicroStrategy distribution services send out emails using G-Suite SMTP service.Hope this helps!

One of the common questions that an IT team would have is to understand the best practice or various methods of deploying a mobile application to large user base. This technical paper describes various distribution methods of a mobile app developed using MicroStrategy.Depending on the situation, there are different ways to deploy MicroStrategy dashboards to a mobile device. There is a way to leverage the MicroStrategy Mobile app, and there is even a way to create a custom app with MicroStrategy Mobile embedded.Configuration links contain all the server, project, and authentication information to configure the mobile client app with your data. To create a configuration link, please refer to TN 33919 in the MicroStrategy knowledge base.

The mobile app can be configured with multiple projects from a single server or multiple projects from multiple servers using a mobile configuration link.

To configure multiple projects from a single server click on Configure New Mobile Server.

After entering the mobile server details, click on Configure New Project and enter the server, project, and authentication information.

To configure another project from the same server, click on Configure New Project again, repeat the steps, and save configuration.

Now generate the configuration URL to be sent to the mobile devices using the Generate URL action button.

To configure multiple projects from multiple servers, click on Configure New Mobile Server and repeat the above steps.

• Easy to configure.
• Recommended when the number of end users is low.

• The configuration link needs to be updated to the end users every time there is a change in mobile configuration settings.
• Not recommended for a large user base.
• All the projects that are configured are displayed in the list view.

Design a dashboard with Configuration links for different mobile applications as shown below.

Make sure that this dashboard is available in all the projects.

• The list view can be avoided, and an attractive dashboard can be designed for better user interface.
• Recommended for a large user base.

• The dashboard must be modified when a new link is added.
• Time consuming.

A simple HTML page can be created that contains the links for each configuration, supported and hosted at . In this way, users can be directed to go to that URL on their mobile devices and click the link directly to complete their setup.

• Recommended for large user base.
• Easy to configure and maintain.
• Forwarding the configuration link to users every time there is a change in mobile configuration settings is not required.

• User is required to go to the HTML page and click on the configuration link to navigate from one project to another project.

MicroStrategy Mobile app platform lets you build mobile apps without any programming. Because the design process is simplified, you produce more enterprise-class apps in less time.

MicroStrategy Mobile client SDK provides a convenient and easy way to customize and brand your apps without a lot of coding.

• Recommended for large user base.
• Personalized mobile application for the organization.
• Easy to configure and maintain; just download the app from AppStore or PlayStore and install on your mobile devices.
• No need to forward the configuration link to users every time there is a change in mobile configuration settings.

• Time is required for application development.

• MicroStrategy Mobile application is supported only by versions 9.2.1 or above.
• To create a customized MicroStrategy app, the user must have access to MicroStrategy SDK.

This technical paper discusses direct transactions with the database using the Freeform SQL. It describes the different ways of inserting your inputs into the warehouse through a mobile interface, from start (creating a transaction report) to finish.Process Of Implementing A Transactional Dashboard (For Guest Feedback Form)Create a Transactional Table (‘Transac’ in this case) in the Database with the columns that have to be inserted, updated, or deleted during the Transaction.

Import the table into the Catalog and update the schema.Create a Transaction report.

• To create the Transaction report, open the Report editor in MSTR Desktop.
• From the Grid window, select Freeform Sources.
• Select Create Transaction report and click OK.

• Select the proper Database Instance from the list of Data sources and click OK.

• In the Freeform SQL Editor, define the transaction. To define the transaction in the SQL statement pane, right-click an empty area and select the option ‘Insert Transaction’.

• The Transactions options window will open.

• In that window, keep the “Insert only distinct records” check box cleared if you want all records to be inserted when a transaction triggers an update. This action is intended for using Transaction services to update fact tables that store fact data.
• Select the “Insert only distinct records” check box if you want all records to be inserted when a transaction triggers an update. This action is intended for using Transaction services to update lookup tables that store attribute information.
• Click OK.

• In the SQL statement pane, between the Begin Transaction and End Transaction placeholders, type the SQL statement to update, insert, or delete values in the data source.
• In the SQL Statement pane, right-click in the area and select the Define New Input option to define the Input object and choose the object form (Attribute Form/ Metric form).

• In the object field of the Mapping pane, type the name of the input object and press ENTER.

• Set any dummy metric as Output object, as it is mandatory, and click OK.
• Save and close the report.
• Follow the same process for ‘Update’ and ‘Delete’ statements.

Create a Query report, which is a Freeform SQL report (with Select statement to retrieve data from the Transaction Table) or MSTR Grid report (with Attributes and Metrics to retrieve data from the Transaction Table) that helps to display the Transaction data in the document interface.Create a Transaction dashboard that fits the iPad screen in the MicroStrategy desktop with required text fields and labels requested by the customer. Save the document.

• Open the document on the web in design mode. Right-click on any text box and select the ‘configure transaction’ option. The configuration editor opens as shown below.
• Choose the transaction report (Transac_Report1) that you want to configure with the dashboard. This is where the transaction report is associated with the document.
• The Input Properties section of the editor gets auto-populated with Inputs available on the Transaction report.

• Select the appropriate fields for each transaction input and select the control style from the drop-down list (Text, Slider, Switch, Toggle, and List), click OK and save the document.

• Insert an Action Selector Button (new in MicroStrategy 9.2.1) and set the grid associated with the Transaction report as its target. In the selector properties editor, set the name and action type as ‘Submit’.

To display the transaction data on the document interface, choose the Query report created on the Transaction Table as dataset, select the option Run a new report or document in action selector button properties and formatting and choose the Query report.

Open the document in iPad and fill in the details per the instructions provided. Different selectors are used to provide different inputs. Some of the selectors are listed below.Enter the input text directly by typing it in (e.g., Guest Name, Email address, etc.)

Select the input value from the list of options provided.

Select the input values from the range of values provided by sliding.

Choose an existing or take a new photo to upload it to the server on which the MicroStrategy I-Server has been installed. Refer to TN Key: 38007 in the MicroStrategy knowledge base for the procedure to implement this widget.

After entering all the details, click on the ‘action selector button’ (In this case, Submit). A message will appear after the submission confirming the transaction. The results will be written back to the ‘Transac’ table in the warehouse and the data will be displayed.

• Transaction services is supported only in MicroStrategy versions 9.2.1 and above.
• Users must have the latest version of the MicroStrategy App installed on iPad.
• It is always better to have a dedicated transactional table created in the database instead of performing transactions on the existing tables.
• Users must have Read/Write access to transactional table in the database or warehouse.

This paper provides an overview of the steps to establish ODBC connectivity to and from Windows and Linux Operating Systems

1. Download the driver from the Cloudera downloads site. Users will have to register and create a new account on Cloudera’s website before downloading the connector. (http://go.cloudera.com/microstrategy_connector_download)
2. Install the certified ODBC driver.
3. After the driver is installed, run the ODBC Data Source Administrator.
4. In the ODBC Data Source Administrator window, click the System DSN tab, then click Add.
5. Select the Cloudera ODBC Driver for Apache Hive and click Finish.
6. The Hive ODBC DSN Configuration dialog box appears.
7. Fill in the fields with the details of your data source. The data source could be either a Cloudera Impala server or an Apache Hive server.
8. • Enter the hostname or IP address and the port number. To connect to Impala, specify the details for any node in the cluster that is running the impalad daemon.
   • For Impala, leave the Type field blank when connecting to an Impala node secured with Kerberos authentication, or enter HS2NoSASL for the Type field if the node is not secured by Kerberos. For Hive, always leave the Type field blank.
   • The default port number is 21050 for an Impala node, or 10000 for an Apache Hive server.
   • When connecting to a cluster that has Kerberos authentication enabled, fill in the Kerberos principal for the HiveServer2 or Impala service. For example: node1/hiveserver2@myRelm.com

8. Click OK.
9. The installation is now complete

1. Install the 32-bit Cloudera Connector for MicroStrategy for Red Hat on the Linux system that will host the MicroStrategy Intelligence Server.
2. Locate the odbc.ini file found in the home directory of the MicroStrategy installation.
3. Edit the odbc.ini and add the following content at the end of the file to create a new DSN:

[ODBC DATA SOURCES]

IMPALA-SERVER=Hive ODBC Driver

[IMPALA-SERVER]

Driver=odbc_driver_libs_path/libhiveodbc.so.1

Description=Hive ODBC Driver

Host= <provide name of the host server>

Port=<provide port number>

Database=<provide name of the database>

FRAMED=0

Trace=Yes

TraceFile=/tmp/odbc.log

Type=HS2NoSasl[ODBC DATA SOURCES]

HS2=Hive ODBC Driver

[HS2]

Driver=odbc_driver_libs_path/libhiveodbc.so.1

Description=Hive ODBC Driver

Host= <provide name of the host server>

Port=<provide port number>

Database=<provide name of the database>

FRAMED=0

Trace=Yes

TraceFile=/tmp/odbc.log

1. Save and close the odbc.ini file.
2. Edit the ODBC.sh file found in the location <MSTR_HOME_PATH>/env and add the section below to the end of the file. Replace the <FULL_PATH_TO_LOCATION_OF_DRIVER> with the location where the driver is installed.

#

# ODBC Driver for Hive

#

HIVE_CONFIG='<FULL_PATH_TO_DRIVER>/cloudera/20v2’

if [ “${HIVE_CONFIG}” != ‘<HIVE_CONFIG>’ ]; then

export HIVE_CONFIG

mstr_append_path LD_LIBRARY_PATH “${HIVE_CONFIG:?}”/lib

export LD_LIBRARY_PATH

fi

Save and close the ODBC.sh file
Add the following entry to the odbcinst.ini file, which is located in the Home Directory of the MicroStrategy installation on Linux:
[ODBC DRIVERS]

Hive Driver=Installed

[Hive Driver]

Driver=odbc_driver_libs_path/libhiveodbc.so.1

Description=Hive Driver

Setup=odbc_driver_libs_path/libhiveodbc.so.1

APILevel=2

ConnectFunctions=YYY

DriverODBCVer=1.0

FileUsage=0

SQLLevel=1
Note: Substitute the full path to the ODBC driver libraries for odbc_driver_libs_path.Save and close the odbcinst.ini file.
Once the ODBC Connectivity is set up, you can create a new Database Instance.

1. Setting up the environment to use the MicroStrategy Mobile Application.
2. Performing the rebranding actions.
3. Building the project for the rebranded MicroStrategy Mobile Application.

Each of these steps is described in detail below
Open the MicroStrategyMobile.xcodeproj using Xcode, located in the MicroStrategyMobile folder. Based on customizing the iPad/iPhone application, select the appropriate MicroStrategyMobileIphone/MicroStrategyMobileIpad scheme. The resulting MicroStrategy Mobile Xcode file when opened in Xcode will appear as shown below.

For rebranding actions, select the appropriate property list file, Info_Iphone.plist or Info_Ipad.plist for iPhone and iPad respectively, and follow the procedure below.The information property Bundle display name stores the value of the name used for the application. To give your application a custom name, update the value of this property with the name of your application and save your changes.

To confirm that the application compiles and deploys successfully, it is necessary to make sure that the appropriate scheme (MicroStrategyMobileIPhone or MicroStrategyMobileIPad for iPhone and iPad respectively) is correctly selected. Click the Run button to compile and deploy the application to a simulator. Confirm that it compiles and deploys successfully.

According to Apple Inc., there are two ways to distribute an iPhone or an iPad application to your users.You can enroll in the iOS Developer Program to distribute your iPhone or iPad application to your users through the App Store. After you develop the application, it must be submitted to Apple for approval; after receiving the approval, the application can be made available for distribution through the App Store. Normally this developer license costs about $99/year.You can enroll in the iOS Developer Enterprise Program to develop and deploy iPhone or iPad applications within your organization. You can use the Enterprise Developer’s license to seamlessly integrate iPhone or iPad. The Enterprise Developer’s license costs around $299/year.

The portlets on a portal page can display information from a different source, manage user preferences, maintain security, and communicate with other portlets. The end-user essentially sees a portlet as a specialized content area within a Web page that occupies a small window in the portal page.

An example Enterprise Information Portal (EIP) containing 3 different portlets (a, b & c)

MicroStrategy portlets allow MicroStrategy Web to be easily integrated and configured on portal environments. MicroStrategy provides portlets for the following portal servers:

1. Microsoft SharePoint
2. IBM WebSphere
3. Oracle WebLogic
4. SAP NetWeaver
5. Liferay
6. DotNetNuke
7. Drupal

All of these portlets, modules, and blocks offer a wide range of features, including the full functionality of MicroStrategy Web and access to the MicroStrategy Web SDK for customization. The easiest way to integrate MicroStrategy Web in a portal environment is to use one of these out-of-the-box portlets.

The benefits of using MicroStrategy portlet include:When you design a portal that displays MicroStrategy BI data, you have a rich array of choices related to the BI content. You can choose the number of MicroStrategy portlets to be included and how they will be shown on the portal page. You can add multiple MicroStrategy portlets with non-MicroStrategy portlets and configure each portlet to display folders, reports, documents, and other MicroStrategy functionalities.MicroStrategy portlets have a built-in ability called portlet-to-portlet (P2P) communication, which allows them to communicate with each other and with non-MicroStrategy portlets as well. This feature allows choices made in one portlet to affect the content displayed in other portlets. By enabling portlet-to-portlet communication, users can dynamically access the data needed to make decisions.This feature provides secure and seamless access to MicroStrategy BI content, without additional log-ins, by leveraging the authentication mechanisms of the portal, portlet, and MicroStrategy Web.This feature allows only authenticated users to access the requested applications or resources or to execute a requested action. When MicroStrategy portlet is used in any portal, there are different levels of authorization:

• Portal authorization
• Portlet authorization
• MicroStrategy Web authorization

This feature allows MicroStrategy portlets to have access to features and to interact with MicroStrategy Web with functions such as drilling, pivoting, and sorting.Users can personalize credentials, locale information, and BI content to be displayed, provided the portal administrator provides permissions to do so.All MicroStrategy portlets can be used as is or customized in the same way that MicroStrategy Web can be customized. Basic customizations can be done using only URL parameters or context menu options; complex customizations require MicroStrategy SDK.Redundant CPU cycles associated with unnecessarily refreshing entire portal pages have been eliminated, since MicroStrategy portlets were developed using AJAX/Web 2.0-based technology.MicroStrategy portlets can be used in portal environments with firewalls that block portlet content that does not come through the port used by the portal.MicroStrategy portlets come in two out-of-the-box forms, a basic MicroStrategy portlet and a master MicroStrategy portlet. The basic MicroStrategy portlet is used to display MicroStrategy BI data; the master MicroStrategy portlet can also display BI data, but its primary function is to send messages to other portlets (that is, to perform portlet-to-portlet communication).IBM WebSphere Portal Server provides the infrastructure to build and deploy portals and uses its own mechanism for incorporating external application content into the portal server. It provides common services, such as application connectivity, integration, administration, and presentation. It also provides its own API for portlet development, for storing user log-in credentials, for storing personalization options in a repository, and for managing sessions. MicroStrategy portlets allow users to take advantage of the storage and repository mechanisms of the IBM WebSphere portal server, without making any adjustments or changes, while providing the full complement of portlet features.To configure MicroStrategy portlet for an IBM WebSphere Portal, the administrator must deploy the MicroStrategy portlet and choose the content to display. The administrator must configure the MicroStrategy portlet using the WebSphere portal administration screen. These settings allow the portal server to retrieve data from MicroStrategy Web and MicroStrategy Intelligence Server. Settings that can be configured include:

• Environment Settings
• MicroStrategy URLs
• Default display settings (size of the Portlet Window to be displayed within the portal)

When Microstrategy portlets are installed, the values for some settings are provided, but the administrator can change the reset the values and also provide values for others that have not been set.To configure properties for a MicroStrategy portlet:

Log on to the WebSphere portal server as an administrator.

• Click the Administration tab at the top right of the screen.
• In the left panel of the Portal Administration page, click Portlet Management/Portlets.
• Under Manage Portlets in the right panel, in the Search text box search the MicroStrategy portlet that you want to configure — either the basic MicroStrategy portlet or the MicroStrategy master portlet.
• Select the MicroStrategy portlet whose properties you want to configure and click the configure icon to its right.
• On the Manage Portlets panel, add or change the values of the portlet settings as required to configure your MicroStrategy portlet.

The image below shows an IBM WebSphere portal page with a number of different portlets displayed within it. One MicroStrategy portlet displays BI data, while the other portlets display a variety of non-MicroStrategy data. MicroStrategy portlets can communicate with each other and with non-MicroStrategy portlets. In the MicroStrategy portlet, each user can see and interact only with data that is allowed by his or her security profile.

The IBM WebSphere Portal Server supports single sign-on through a mechanism that assists the MicroStrategy portlet in retrieving one of several representations of a user’s authenticated identity, which the portlet can then pass to the back-end MicroStrategy Web application. In this way, the IBM WebSphere portal and the MicroStrategy portlet act like an authentication proxy to the back-end application. The user can authenticate once when logging in to WebSphere, and the user’s identity is then passed on to the MicroStrategy Web application without requiring additional identity verification from the user.The administrator must configure the type of authentication that should be used to log in to MicroStrategy Web. The following supported MicroStrategy authentication modes can be used to authenticate a user accessing MicroStrategy Web through a portlet in an IBM WebSphere portal page:

• Standard
• NT (Windows)
• Guest (anonymous)
• LDAP
• Database
• Trusted
• Integrated

Installed MicroStrategy Intelligence Server and configured a valid MicroStrategy project

The silent install can be used for

• Deployment with Microsoft System Management Server (SMS)
• OEM installations
• Silent installation through SMS environments

This paper covers how to perform a silent installation and silent configuration on a Windows environment using response files.
Step 1

Create the response file (response.ini) for MSTR installation.
Any text editor can be used to create a response.ini file.
Below is an example of a response file to install Desktop and Architect components:

[Installer] HideAllDialogs=TRUE
ForceReboot=TRUE
StopAllServices=TRUE[Welcome] HideDialog=TRUE
RemoveAll=FALSE[UserRegistration] HideDialog=TRUE
UserName=UserNameHere
CompanyName=CompanyNameHere
LicenseKey=CustomerLicenseKeyHere[SetupType] HideDialog=TRUE
Type=TYPICAL[SuiteTarget] HideDialog=TRUE
TargetDirectory=C:\Program Files\MicroStrategy[ComponentSelection] HideDialog=TRUE

### Visible Components ###
DesktopAnalystVisible=TRUE
DesktopDesignerVisible=TRUE
ArchitectVisible=TRUE
ProjectBuilderVisible=TRUE
FunctionPluginVisible=TRUE
CommandManagerVisible=FALSE
EnterpriseManagerVisible=FALSE
ObjectManagerVisible=FALSE
SDKVisible=FALSE
ServerAdminVisible=FALSE
IServerVisible=FALSE
IServerOLAPServicesVisible=FALSE
IServerReportServicesVisible=FALSE
IServerDistributionServicesVisible=FALSE
IServerTransactionServicesVisible=FALSE
IntegrityManagerVisible=FALSE
WebAnalystVisible=FALSE
WebProfessionalVisible=FALSE
WebReporterVisible=FALSE
WebServerASPNETVisible=FALSE
WebServerJSPVisible=FALSE
WebServicesASPNETVisible=FALSE
WebServicesJSPVisible=FALSE
OfficeVisible=FALSE
MobileVisible=FALSE
MobileClientVisible=FALSE
MobileServerASPVisible=FALSE
MobileServerJSPVisible=FALSE
TutorialReportingVisible=FALSE
WebMMTVisible=FALSE
AnalyticsModulesVisible=FALSE
NCSAdminVisible=FALSE
DeliveryEngineVisible=FALSE
SubscriptionPortalVisible=FALSE
TutorialDeliveryInstallVisible=FALSE
TutorialDeliveryConfigureVisible=FALSE
SequeLinkVisible=FALSE
PortletsVisible=FALSE
TM1ConnectorVisible=FALSE
GISConnectorsVisible=FALSE

### Components To Install (TRUE) or Remove
(FALSE) ###
DesktopAnalystSelect=TRUE
DesktopDesignerSelect=TRUE
ArchitectSelect=TRUE
ProjectBuilderSelect=TRUE
FunctionPluginSelect=TRUE
CommandManagerSelect=FALSE
EnterpriseManagerSelect=FALSE
ObjectManagerSelect=FALSE
SDKSelect=FALSE
ServerAdminSelect=FALSE
IServerSelect=FALSE
IServerOLAPServicesSelect=FALSE
IServerReportServicesSelect=FALSE
IServerDistributionServicesSelect=FALSE
IServerTransactionServicesSelect=FALSE
IntegrityManagerSelect=FALSE
WebAnalystSelect=FALSE
WebProfessionalSelect=FALSE
WebReporterSelect=FALSE
WebServerASPNETSelect=FALSE
WebServerJSPSelect=FALSE
WebServicesASPNETSelect=FALSE
WebServicesJSPSelect=FALSE
OfficeSelect=FALSE
MobileSelect=FALSE
MobileClientSelect=FALSE
MobileServerASPSelect=FALSE
MobileServerJSPSelect=FALSE
TutorialReportingSelect=FALSE
WebMMTSelect=FALSE
AnalyticsModulesSelect=FALSE
NCSAdminSelect=FALSE
DeliveryEngineSelect=FALSE
SubscriptionPortalSelect=FALSE
TutorialDeliveryInstallSelect=FALSE
TutorialDeliveryConfigureSelect=FALSE
SequeLinkSelect=FALSE
PortletsSelect=FALSE
TM1ConnectorSelect=FALSE
GISConnectorsSelect=FALSE

[Programfolder] HideDialog=TRUE
Name=MicroStrategy[Summary] HideDialog=TRUE[Finish] HideDialog=TRUEstep 2

Create the setup.iss file:

[InstallShield Silent] Version=v7.00
File=ResponseFile
[File Transfer] OverwrittenReadOnly=NoToAll[Application] Name=MicroStrategy
Version=9.3.1 #Represent the version of the product#
Company=MicroStrategy
Lang=LanguageValue
[{8CCF3F6C-55B7-4A27-8C68-ADF21D0585A2}
-DlgOrder] Count=0
1. The Version in the setup.iss file must match the MicroStrategy version that you are installing.
2. Options for Language Value are:

• Danish                L0006
• Dutch                  L0019
• English               L0009
• French               L0012
• German             L0007
• Italian                L0016
• Japanese           L0017
• Korean               L0018
• Portuguese       L0022
• Spanish              L0010
• Swedish             L0029

3. Run the silent install:

INSTALL_PATH\setup.exe –ResponseFile=”C:\response.ini” -s -f1”C:\setup.iss” -f2”C:\setup.log”
The –s parameter in the above syntax indicates that the installation is to be completely silent.

4. If a restart is needed after the completion of the installation, the machine will be automatically restarted.
5. The results of the silent installation can be checked in the setup.log file.

ResultCode = 0 implies a successful silent installation.It is possible to configure the server definition, project source names, and the metadata repository using a Configuration Wizard response.ini file.

This file may be generated in one of two ways:

• Create using the MicroStrategy Configuration Wizard
• Create a response.ini file manually using a text editor

To create a response file using MicroStrategy Configuration Wizard:

• Open the MicroStrategy Configuration Wizard.
•  Select a task and follow the steps.
• Any configuration tasks you complete with the Configuration Wizard can be saved to a response file.
• Once you reach the Summary page for a configuration, click Save.
• Specify a name and location to save the response file in the Save dialog box.

• Open the MicroStrategy Configuration Wizard.
• Click Load. The Open dialog box displays.
• Browse to the path where the response file is saved and click Open. The Summary page opens.
• An overview of all of the configuration tasks performed by the response file is displayed. Review the configuration tasks and click Finish to perform the configuration. The summary information is updated as the configurations are completed, providing a way to track the progress of the configurations.

Type the following command in the Windows command line:

macfgwiz.exe -r “Path\response.ini”
where Path\ is the fully qualified path to the response file.
For example, the common location of a response file is:
C:\Program Files\Common Files\MicroStrategy\response.ini.
To configure automatically, add the following lines at the bottom of the automated installation response.ini file:
[PostInstall] RunExternalApp=”C:\Program Files\Common Files\MicroStrategy\macfgwiz.exe” -r “C:\ response.ini”
This will execute the MicroStrategy Configuration Wizard, and configure as specified in the response.ini file that was created.

• An installation must be performed under an account that has administrative privileges on the target machine. Administrator privileges are required to register the necessary libraries and services, and to modify the registry locations associated with the MicroStrategy platform. Failure to install with an administrator account may result in the MicroStrategy platform behaving unexpectedly, if it runs at all.
• Make sure to check that all file paths are entered with correct spacing.
• Your license key determines which MicroStrategy components will be available for installation. For example, if your license key does not include MicroStrategy Desktop Designer, then you cannot use DesktopDesignerVisible=TRUE and DesktopDesignerSelect=TRUE to install these components.
• The response.ini file only automates and makes the MicroStrategy installation selection screens silent, not the Install Shield application. To make the entire installation silent, a setup.iss file is needed to configure the silent functionality for the Install Shield.
• The response.ini file needs to be in the same location as the setup.exe installation file. The silent installation functionality of the MicroStrategy installer is programmed to look only within the same folder as the setup.exe file.
• If both response.ini and setup.iss files are in the same location as the setup.exe, the setup.iss will be used in place of the response.ini file. To use both, store the setup.iss in a location different than the response.ini and setup.exe files.
• There is a response.ini used by MicroStrategy Installation Wizard to install MicroStrategy products silently, and there is a response.ini file used by MicroStrategy Configuration Wizard to set up the MicroStrategy environment.
• It is recommended that you always create the configuration response file through the GUI mode of the Configuration Wizard. However, you can also modify a response file with a text editor to make minor changes, such as entering different user login and password information