Configure the Service Factory
Assemblies can only be written inside Workspaces. This allows for greater flexibility, extraction, and packaging, and it provides the ability to create Dynamic Dashboards and Dynamic Cubes.
You can implement a Service Factory, as described in the following sections, to use Workspaces capabilities.
Runtime Logic
The Service Factory is a dispatcher object that routes requests to run rules to specific objects called Services that can satisfy these requests.
In a basic setup, a Service Factory can have a single service for each type of rule. For example, one is for Data Management calls, and one is for XFBR calls. However, a Service Factory can also invoke multiple services of a specific type, depending on context variables. For example, it could route calls for Data Management jobs to one service from Monday to Friday and then to a different service from Saturday to Sunday.
It is not required to provide a service for every supported type.
Example: If the Service Factory is not used for requests of that type, it may use the traditional approach, and everything will function correctly.
Figure 1 - Example Service Factory execution
Configuration
Step 1: Create a Maintenance Unit for all assemblies within a Workspace.
The first step is organizational, designed to keep all rules within a single location. Create a Maintenance Unit within the Workspace to hold all necessary assemblies. The following image displays multiple Maintenance Units in the Workspace, but only DynamicCode Maintenance Unit contains assemblies. This will be the central location for all rules.
Step 2: Create an assembly file for the Service Factory.
The second step is to create an assembly file with the source code type of Service Factory.
The Service Factory assembly file is needed to take advantage of all items used within assemblies. It should look similar to the following image (the example uses C#):
The code allows you to create the following objects:
-
Components
-
Dashboards
-
DataManagementStep
-
DataSet
Dynamic Dashboard
-
Finance Business Rules
-
SqlTableEditor
-
TableViews
-
XFBRString
If you are not using any of the objects listed, keep them commented out in the code. Otherwise, you will receive a syntax error when compiling. For example, if you only need the DynamicDashboard call, the Service Factory would look similar to the following image:
Step 3: Configure the Workspace Assembly Service property.
This last step allows the entire Workspace to use the new Service Factory file so that your rules run correctly.
IMPORTANT: Assembly files will not run correctly if you skip this step.
Go to the Workspace, and update the Workspace Assembly Service to {WsAssemblyName}.{ServiceFactoryName}. For this example, that would be DynamicCode.WsAssemblyFactory.
You can also do this on any given Maintenance Unit. As a best practice, you can keep all assembly files in a single Maintenance Unit. You can designate the Workspace and Workspace Maintenance Unit level in all actions.
Reference the Service Factory in Properties
Service Factories can be referenced from configuration properties in different ways, depending on their location.
assemblyName.factoryName
This will look for a Service Factory File called factoryName in the Assembly called assemblyName.
This can be used on properties of:
-
Maintenance Unit
-
Workspace
WSMU
This will look for the Service Factory specified on the Maintenance Unit containing the object. If it cannot find it, it will search for the Service Factory specified on the Workspace containing the object. It will fail if it is empty.
This can be used on properties of:
-
Dashboard Components
WS
This will look for the Service Factory specified on the Workspace containing the object. It will fail if it is empty.
This can be used on properties of:
-
Dashboard Components
Workspace.workspaceName.maintenanceUnitName.WSMU
This will look for the Service Factory specified on the Maintenance Unit called maintenanceUnitName in Workspace called workspaceName. It will fail if it is empty.
NOTE: You can specify a Namespace Prefix as workspaceName.
If the specified Maintenance Unit is not in the Workspace containing the object that originates the call, or this syntax is used in Cube Views, the specified Workspace must be set to Is Shareable Workspaces.
This can be used on properties of:
-
Cube Views
-
Dashboard Components
-
Data Management Steps
Workspace.workspaceName.WS
This will look for the Service Factory specified on Workspace workspaceName. It will fail if it is empty.
NOTE: You can specify a Namespace Prefix as workspaceName.
If the specified Workspace is not the one containing the object that originates the call, or this syntax is used in Cube Views or Cube Properties, the specified Workspace must be set to Is Shareable.
This can be used on properties of:
-
Cube Properties
-
Cube Views
-
Dashboard Components
-
Data Management Steps
Workspace.Current.maintenanceUnitName.WSMU
Workspace.Current.Current.WSMU
Workspace.Current.WS
The "Current" keyword can be used to reference the Workspace or Maintenance Unit, without having to fully spell out their names when they contain the object originating the call. This makes the configuration more robust because references will not break if these containers are renamed or duplicated. This syntax will still follow the same Workspace "Is Shareable" and application restrictions and behave the same as the explicit syntax.
These can be used on properties of:
-
Cube Views
-
Dashboard Components
-
Data Management Steps
Examples
Dashboard Components
In this example, you implemented a component service with a function name of “SaveRecord”. This service is enabled by the "MyFactory" Service Factory - Assembly File specified on the same "MyMU" Maintenance Unit within the "MyWorkspace" Workspace, which contains the button component which will invoke the function when selected on a dashboard.
In the property Selection Changed Server Task Arguments of the "MyButton" component, you can have:
{WSMU}{SaveRecord}{}
To invoke the same rule, but from a button component that lives in another Maintenance Unit named "MyMU" in the same Workspace, use:
{Workspace.Current.MyMU.WSMU}{SaveRecord}{}
To invoke the same action from a button component in another Workspace named "MyWorkspace", you must set the property of “MyWorkspace”, and change the Workspace’s “Is Shareable Workspace” field to True, and then use:
{Workspace.MyWorkspace.MyMU.WSMU}{SaveRecord}{}
Data Management Steps
Data Management steps require the expanded syntax. For example, Workspace.MyWorkspace.MyMU.WSMU. However, to make the configuration more robust, if the factory is specified on the same Maintenance Unit that contains the step, use the "Current" keyword:
Member Lists
Cube Views require all referenced factories to be in a shareable Workspaces, even if Service Factories are in the same Workspace as the Cube View. The syntax must be explicit.
In this example, a Member List parameter called “MyMemberList” was created, provided by a Service Factory specified in the properties of Maintenance Unit “MyMU” in Workspace “MyWorkspace”.
To invoke it from a Cube View, use this syntax:
[Workspace.MyWorkspace.MyMU.WSMU,MyMemberList]
GetDataCell
The same considerations apply as for Member Lists.
Example: GetDataCell(“BR#[Workspace.MyWorkspace.MyMU.WSMU,MyDataCellFunction]”):Name(My Check)