Datenaktions-Plug-ins nutzen das Datenaktions-Framework, um benutzerdefinierte, datengesteuerte Aktionen bereitzustellen, die eng in die Benutzeroberfläche von Oracle Analytics integriert sind.
Wenn ein Benutzer eine Datenaktion aufruft, übergibt der Datenaktionsmanager den Anforderungskontext (z.B. qualifizierte Datenreferenz, Kennzahlwerte, Filter und Metadaten) an das Datenaktions-Plug-in, das für das Anforderungshandling verantwortlich ist. Oracle stellt vier Typen von Datenaktions-Plug-ins bereit: CanvasDataAction
, URLNavigationDataAction
, HTTPAPIDataAction
und EventDataAction
. Sie können diese Datenaktions-Plug-in-Typen zusammen mit ihren abstrakten Basisklassen erweitern und so eigene Datenaktionen bereitstellen.
Zu den Datenaktionskategorien gehören "Zu URL navigieren", "HTTP-API", "Zu Leinwand navigieren" und "Ereignisaktionen":
GET/POST/PUT/DELETE/TRACE
-Befehle an eine HTTP-API und öffnet keine neue Registerkarte. Stattdessen wird der HTTP-Statuscode untersucht, und eine transiente Erfolgs- oder Fehlermeldung wird angezeigt.Die Datenaktions-Kategorietypen Zu URL navigieren und HTTP-API können beide eine Tokensyntax verwenden, um Daten oder Metadaten von der Visualisierung in die Parameter URL
und POST
zu injizieren.
URL-Tokenersetzung
HTTP-Datenaktionen können Token in URLs durch Werte aus dem Kontext ersetzen, die an die Datenaktion übergeben werden. Beispiel: Werte der qualifizierten Datenreferenz, Filterwerte, Benutzername, Arbeitsmappenpfad und Leinwandname.
Token | Hinweise | Ersetzen durch | Beispiel | Ergebnis |
---|---|---|---|---|
${valuesForColumn:COLUMN} |
N/V | Spaltenanzeigewerte aus der qualifizierten Datenreferenz. | ${valuesForColumn: "Sales"."Products"."Brand"} |
BizTech,FunPod |
${valuesForColumn:COLUMN, separator:"/"} |
Jedes Token, das durch mehrere Werte ersetzt werden kann, unterstützt die optionale "separator"-Option. Das Trennzeichen (separator ) ist standardmäßig ein Komma (,). Sie können aber jede beliebige Zeichenfolge festlegen. Sie können doppelte Anführungszeichen in dieser Zeichenfolge mit einem umgekehrten Schrägstrich (\) maskieren. |
Spaltenanzeigewerte aus der qualifizierten Datenreferenz. | ${valuesForColumn: "Sales"."Products"."Brand"} |
BizTech,FunPod |
${valuesForColumn:COLUMN, separationStyle:individual} |
Als separationStyle wird standardmäßig delimited verwendet. Sie können die Eigenschaft jedoch auch auf individual setzen, wenn der Benutzer separate URL-Parameter für jeden Wert generieren muss. |
Spaltenanzeigewerte aus der qualifizierten Datenreferenz. | &myParam=${valuesForColumn: "Sales"."Products"."Brand"} |
&myParam=BizTech&myParam=FunPod |
${keyValuesForColumn:COLUMN} |
N/V | Spaltenschlüsselwerte aus der qualifizierten Datenreferenz. | ${keyValuesForColumn:COLUMN} |
10001,10002 |
${env:ENV_VAR} |
Unterstützte Umgebungsvariablen: sProjectPath , sProjectName , sCanvasName , sUserID und sUserName . |
Eine Umgebungsvariable. | ${env:'sUserID'} |
myUserName |
Sie können einen Kontext definieren, der beim Aufrufen einer Datenaktion übergeben wird.
Beim Erstellen der Datenaktion legen Sie fest, wie viel des Kontextes an die Datenaktion übergeben wird.
Qualifizierte Datenreferenz
Beim Aufruf der Datenaktion wird eine qualifizierte Datenreferenz für jeden markierten Datenpunkt mit einem Array von LogicalFilterTree
-Objekten generiert. Ein LogicalFilterTree
besteht aus mehreren LogicalFilterNode
-Objekten, die in einer Baumstruktur angeordnet sind. Zu diesem Objekt gehört Folgendes:
Umgebungsvariablen
Zusätzlich zu den Daten und Metadaten, die die einzelnen markierten Datenpunkte beschreiben, benötigen einige Datenaktionen unter Umständen auch weiteren Kontext, der die Umgebung beschreibt, von der aus die Datenaktion aufgerufen wird. Beispiele für derartige Umgebungsvariablen:
Sie erstellen Datenaktionen mit API-Klassen.
AbstractDataAction
-Klasse erben:
CanvasDataAction
URLNavigationDataAction
HTTPAPIDataAction
EventDataAction
DataActionPluginHandler
verwaltet.DataActionManager
verarbeitet.Es gibt mehrere verschiedene Typen von Modellklassen für Datenaktionen.
AbstractDataAction
Diese Klasse ist verantwortlich für:
+ invoke(oActionContext: ActionContext, oDataActionContext:DataActionContext) <<abstract>>
Ruft die Datenaktion mit dem übergebenen Kontext auf (darf nur vom DataActionManager
aufgerufen werden).
+ getGadgetInfos(oReport): AbstractGadgetInfo[] <<abstract>>
Erstellt die GadgetInfos
, die für das Rendern der Benutzeroberflächenfelder zur Bearbeitung dieses Datenaktionstyps verantwortlich sind, und gibt diese zurück.
+ validate() : DataActionError
Validiert die Datenaktion und gibt Null zurück, wenn sie gültig ist, oder DataActionError
, wenn sie ungültig ist.
+ getSettings():JSON
Serialisiert das Knockout-Modell der Datenaktion als JSON für die Aufnahme in den Bericht (verwendet komapping.toJS(_koModel)).
+ createNameGadgetInfo(oReport) : AbstractGadgetInfo
Erstellt die GadgetInfo
, die das Feld Name der Datenaktion rendern kann, und gibt diese zurück.
+ createAnchorToGadgetInfo(oReport) : AbstractGadgetInfo
Erstellt die GadgetInfo
, die das Feld Verankern mit der Datenaktion rendern kann, und gibt diese zurück.
+ createPassValuesGadgetInfo(oReport) : AbstractGadgetInfo
Erstellt die GadgetInfo
, die das Feld Werte übergeben der Datenaktion rendern kann, und gibt diese zurück.
Unterklassen benötigen möglicherweise nicht alle von der Basisklasse bereitgestellten GadgetInfo
s und müssen daher nicht unbedingt all diese Methoden aufrufen. Da das Rendering der einzelnen Felder auf diese Weise getrennt ist, können Unterklassen die erforderlichen Gadgets flexibel auswählen. Einige Unterklassen stellen unter Umständen sogar eine andere Implementierung dieser gängigen Datenaktionsgadgets bereit.
CanvasDataAction, URLNavigationDataAction, HTTPAPIDataAction, EventDataAction
Dies sind die konkreten Klassen für die grundlegenden Typen von Datenaktionen. Diese Klassen stellen die generische Benutzeroberfläche für diese Datenaktionstypen bereit. Sie können auch als praktische Basisklassen für die Erweiterung durch benutzerdefinierte Datenaktions-Plug-ins dienen.
GET/POST/PUT/DELETE/TRACE
-Anforderung an eine HTTP-API gesendet und die HTTP-Antwort
programmgesteuert verarbeitet.Jede Klasse ist verantwortlich für:
invoke(oActionContext: ActionContext, oDataActionContext:DataActionContext)
Diese Methode sollte die Datenaktion aufrufen, indem die im KOModel definierten Eigenschaften mit dem angegebenen DataActionContext
-Objekt kombiniert werden.
getGadgetInfos(oReport): AbstractGadgetInfo[]
Diese Methode sollte:
AbstractGadgetInfos
erstellen;createXXXGadgetInfo()
-Methoden aufrufen, die die jeweilige AbstractGadgetInfo
an das Array übertragen;Unterklassen dieser konkreten Klassen müssen möglicherweise nicht alle von den jeweiligen Superklassen bereitgestellten Gadgets in ihren benutzerdefinierten Benutzeroberflächen verwenden. Da die Erstellung der einzelnen Gadgets auf diese Weise getrennt ist, können Unterklassen die erforderlichen Gadgets flexibel auswählen.
DataActionKOModel, ValuePassingMode
Die DataActionKOModel
-Klasse stellt das gemeinsame Basis-KOModel für die verschiedenen Unterklassen von AbstractDataAction
bereit. Siehe DataActionKOModel-Klasse.
Es gibt mehrere verschiedene Serviceklassen für Datenaktionen.
DataActionManager
Die gesamte Kommunikation mit DataActionManager
verwendet ClientEvents
.DataActionManager
. Dadurch werden Event-Handler für Folgendes implementiert:
DataActionContext, EnvironmentContext
Beim Aufruf einer Datenaktion enthält die DataActionContext
-Klasse den Kontext, der an das Ziel übergeben wird.
getColumnValueMap()
Gibt eine Map mit Attributspaltenwerten nach Attributspaltennamen zurück. Diese definieren die qualifizierte Datenreferenz für die Datenpunkte, aus denen die Datenaktion aufgerufen wird.
getLogicalFilterTrees()
Gibt ein LogicalFilterTrees
-Objekt zurück, das die qualifizierten Datenreferenzen für die jeweiligen Datenpunkte zurückgibt, von denen die Datenaktion aufgerufen wird (Details finden Sie unter InteractionService
).
getEnvironmentContext()
Eine Instanz der EnvironmentContext
-Klasse für eine Beschreibung der Quellumgebung wie:
getProjectPath()
getCanvasName()
getUserID()
getUserName()
getReport()
Gibt den Bericht zurück, aus dem die Datenaktion aufgerufen wird.
DataActionHandler
Die DataActionHandler
-Klasse registriert die verschiedenen Datenaktions-Plug-ins. Die zugehörige API ist mehr oder weniger mit anderen Plug-in-Handlern konsistent (z.B. VisualizationHandler
).
Die DataActionHandler
-Klasse stellt die folgenden öffentlichen Methoden bereit:
getClassName(sPluginType:String) : String
Gibt den vollqualifizierten Klassennamen für den angegebenen Datenaktionstyp zurück.
getDisplayName(sPluginType:String) : String
Gibt den übersetzten Anzeigenamen für den angegebenen Datenaktionstyp zurück.
getOrder(sPluginType:String) : Number
Gibt eine Zahl zurück, mit der die Listen der Datenaktionstypen in der bevorzugten Reihenfolge sortiert werden.
Die DataActionHandler
-Klasse stellt die folgenden statischen Methoden bereit:
getDependencies(oPluginRegistry:Object) : Object.<String, Array>
Gibt eine Abhängigkeitsmap für alle registrierten Datenaktionstypen zurück.
getHandler(oPluginRegistry:Object, sExtensionPointName:String, oConfig:Object) : DataActionPluginHandler
Erstellt eine neue Instanz der DataActionHandler
-Klasse und gibt diese zurück.
DataActionUpgradeHandler
Die DataActionUpgradeHandler
-Klasse wird beim Öffnen eines Berichts vom UpgradeService
aufgerufen.
Die DataActionHandler
-Klasse stellt zwei Hauptmethoden bereit:
deferredNeedsUpgrade(sCurrentVersion, sUpgradeTopic, oDataActionJS, oActionContext) : Promise
Gibt einen Promise
zurück, der einen booleschen Wert ergibt und angibt, ob die angegebene Datenaktion upgegradet werden muss (true
) oder nicht (false
). Die Methode entscheidet, ob die Datenaktion upgegradet werden muss. Dazu wird die Datenaktionsinstanz mit dem Konstruktor der Datenaktion verglichen.
performUpgrade(sCurrentVersion, sUpgradeTopic, oDataActionJS, oActionContext, oUpgradeContext) : Promise
Führt das Upgrade für die angegebene Datenaktion durch und löst den Promise
auf. Das Upgrade selbst wird durch Aufruf der upgrade()
-Methode für die Datenaktion ausgeführt (nur die jeweilige Unterklasse der upzugradenden Datenaktion kann sich selbst upgraden).
getOrder(sPluginType:String) : Number
Gibt eine Zahl zurück, mit der die Listen der Datenaktionstypen in der bevorzugten Reihenfolge sortiert werden.
Eine Datenaktion interagiert mit Oracle Analytics-Code, wenn sie ein Feld auf der Benutzeroberfläche erstellt und wenn ein Benutzer eine Datenaktion aufruft.
Feld für eine neue Datenaktionsinstanz erstellen
Diese Interaktion beginnt, wenn Oracle Analytics das Benutzeroberflächenfeld für eine Datenaktion rendert. Dazu führt das Programm folgende Aktionen aus:
PanelGadgetInfo
als übergeordnete GadgetInfo
für die GadgetInfos
, die von der Datenaktion zurückgegeben werden.getGadgetInfos()
für die Datenaktion auf.GadgetInfos
der Datenaktion als untergeordnete Elemente der PanelGadgetInfo
hinzu, die im ersten Schritt erstellt wurde.PanelGadgetView
, die die PanelGadgetInfo
rendert.HTMLElement
fest, das als Container der PanelGadgetView
dient.PanelGadgetView
als untergeordnete HostedComponent
einer HostedComponent
, die bereits an den HostedComponent
-Baum angehängt wurde.
Dadurch werden die Gadgets der Datenaktion in der Reihenfolge, in der sie in dem von getGadgetInfos()
zurückgegebenen Array stehen, im Bereichsgadget angezeigt.
Datenaktion aufrufen
Diese Interaktion beginnt, wenn der Benutzer eine Datenaktion über die Benutzeroberfläche von Oracle Analytics aufruft (z.B. aus dem Kontextmenü für einen Datenpunkt in einer Visualisierung).
Der Code führt folgende Aktionen aufgrund der Benutzerinteraktion auf:
INVOKE_DATA_ACTION
-Ereignis mit der ID der Datenaktion, der DataVisualization
, aus der die Datenaktion aufgerufen wurde, und einem TransientVizContext
-Objekt.DataActionManager
verarbeitet dieses Ereignis wie folgt:
LogicalFilterTrees
für die markierten Datenpunkte in der angegebenen DataVisualization
.DataActionContext
mit allen Informationen zum Übergeben an das Datenaktionsziel.invoke(oDataActionContext)
für die Datenaktion.Dieses Thema zeigt eine plugin.xml-Beispieldatei für eine CanvasDataAction
-Datenaktion.
Beispiel für plugin.xml
<?xml version="1.0" encoding="UTF-8"?> <tns:obiplugin xmlns:tns="http://plugin.frameworks.tech.bi.oracle" xmlns:viz="http://plugin.frameworks.tech.bi.oracle/extension-points/visualization" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="obitech-currencyconversion" name="Oracle BI Currency Conversion" version="0.1.0.@qualifier@" optimizable="true" optimized="false"> <tns:resources> <tns:resource id="currencyconversion" path="scripts/currencyconversion.js" type="script" optimizedGroup="base"/> <tns:resource-folder id="nls" path="resources/nls" optimizable="true"> <tns:extensions> <tns:extension name="js" resource-type="script"/> </tns:extensions> </tns:resource-folder> </tns:resources> <tns:extensions> <tns:extension id="oracle.bi.tech.currencyconversiondataaction" point-id="oracle.bi.tech.plugin.dataaction" version="1.0.0"> <tns:configuration> { "resourceBundle": "obitech-currencyconversion/nls/messages", "properties": { "className": "obitech-currencyconversion/currencyconversion.CurrencyConversionDataAction", "displayName": { "key" : "CURRENCY_CONVERSION", "default" : "Currency Conversion" }, "order": 100 } } </tns:configuration> </tns:extension> </tns:extensions> </tns:obiplugin>
Die folgenden Dateien und Ordner werden zur Implementierung von Datenaktions-Plug-ins verwendet.
bitech/client/plugins/src/
report
obitech-report
scripts
dataaction
dataaction.js
dataactiongadgets.js
dataactionpanel.js
dataactionupgradehandler.js
obitech-reportservice
scripts
dataaction
dataactionmanager.js
dataactionhandler.js