Test Data Manager

CA TDM - Custom Self Service Tiles 

03-12-2019 11:06 AM



A Self-Service tile is Web Form displayed within the CA Test Data Manager Portal under the self-service catalog menu.


A regular Self-Service Tiles are created using ARD, attached to a TDM project-version and expose it to TDM Portal. CA TDM Portal takes care of converting the variables used and other elements in to a Web Form and displays as a tile under self-service catalog.


A custom Self-Service Tile enables TDEs to write custom code that will be consumed by CA TDM Portal and displayed in the self-service catalog. This code is essentially HTML and JavaScript.


CA TDM Portal displays the HTML form and engages the JavaScript controller with the form. Every aspect of the UI and the controller should be coded. CA TDM’s REST APIs can be leveraged from the JavaScript as well to maximize the potential of the CA TDM Portal.


CA TDM does not impose any sort of validation on the custom code and hence not responsible for functionality, security, performance or any other aspect.


Custom Tile Basics



CA TDM Portal Scans the “subdirectories” in the location:

“~\ProgramData\CA\CA Test Data Manager Portal\ssforms\~”


It scans and looks for a JSON file named – “ssform.json” – A file that species details of the custom form.


This JSON file specifies a HTML file name and a JavaScript file names.


The .JSON file, .HTML file and .JS files must be in the same directory and this directory must be created under the “~\ssforms” directory.


Multiple subdirectories can be created and for every valid ssform.json in these subdirectories a custom self-service tile will be displayed in the self service catalog.


Directory Structure


C:\ProgramData\CA\CA Test Data Manager Portal
















The ssform.json file


It acts as a liaison to communicate to the TDM Portal about the existence of the custom SSForms.

It also links the HTML file and the JavaScript controller that TDM Portal should be aware of.



            "name": "< Tile Name >",

            "description": "< Tile Description >",


            “projectId”: <Project Id to be associated>,

            “projectVersionId”: <Version Id to be associated>,

            "primaryRoute": {

                        "route": "/<URL for the page >",

                        "controller": "<Primary Controller in the JavaScript file >",

                        "template": "<HTML file Name>"


            "resources": {

                        "javascript": [

                        "<Java Script file name 1>",

                           "<Java Script file name 2>"







The HTML File

The HTML file doesn’t need the <html> or <head> tags.

It only needs the <body> tag.

It can also include the CSS classes in the <style> tag. It can also have <script> tag to embed any JavaScript elements.

This HTML is a Sub-Set of TDM Web, hence, all the UI formatting and CSS classes used in the portal will be applicable by default.

TDM Web is based on AngularJS, hence all Angular JS classes and elements can be used in this HTML.


The JavaScript File


One or more java script files can be included.

The JavaScript file must declare a module named ‘TDM’ for TDM Portal to use the elements in it.

One of the JavaScript files should also implement the primary controller specified in the ssform.json file.

The primary controller should be implemented only once in all the JavaScript files.

Any JavaScript code can be written in these files, but JavaScript best practices must be followed to maintain security of the TDM portal because TDM portal does not have control over this code.

Examples and Usage


These examples provide a guide to build custom forms. Each example focuses on a specific functionality.

All Five examples are attached to this blog.

Rename the .js.txt to .js. It was renamed as .js file may not be allowed to download in some environments.


Simple Form


This is a simple form with just one UI element and not much of JavaScript code.

It has bare minimum code for custom ssForm to function.

It doesn’t do much but can be a helpful to understand how Custom SS Forms work with CA TDM Portal.


Form with Simple UI Elements


This form incorporates the usage of the following UI elements:



Text Box

Drop Down List

Multi Select List

Date Picker

Radio Button

Check Box


All the UI elements are styled in default AngularJS style.


Each of these elements are coded in separate <div> tags and can be used in any form being built.

The AngularJS “ng-model” directive is used to bind the UI elements with the JavaScript Code.

Similarly, AngularJS in built object “$scope” is used in the JavaScript to transfer data from HTML to JavaScript and vice versa.


There are multiple variable names used throughout the example code and they can be changes as desired to a more meaningful name to the tile being built.


The “ng-controller” directive is used to specify the controller in the JavaScript file.

The default controller for the whole page is the one that is specified in the ssform.json file but in this example the UI element named “multiSelectList” will use one of the secondary controllers.

This example shows how to use multiple JavaScript files to modularize the code if needed.



Form with Table Alignment


This form focuses on how a custom CSS style can be created, specifically a table layout.

A table layout can be helpful to align UI elements and maximize space usage in a HTML Page.


Its recommended all custom tiles the table style be used to ensure better alignment.


Form with Element Grouping


This form incorporates how “Accordian” and “Collabsable” elements can be used to group UI elements. Angular Bootstrap elements - “uib-accordion” and “uib-collapse” are used.



Form with REST calls and TDM Publish


This form focuses on the following:


Load Form values dynamically from Database using Saved SQLs.

Execute SQLs Saved in DataMaker using REST API and push results back to the UI.

Invoke a TDM publish.

Assign values from web form to variables used in publish.


TDM Saved SQL Usage


In order to dynamically load values from the database to the UI, Best Practice is to use DataMaker’s Saved SQL functionality.


It is recommended that all the SQLs are saved in to a separate TDM project / version to reduce the overhead of coding the Project ID and Version in the JavaScript.


Since we are dealing with SQL queries interacting with DataBase that can hold sensitive data, injecting the Service is not recommended and hence we are using REST API which uses authentication every time it is invoked.



TDM REST API - /TestDataManager/api/ca/v1/connectionProfiles/search/ is used to invoke a specific saved SQL.


URI - /TestDataManager/api/ca/v1/connectionProfiles/search/{TDM Connection Profile Name}?projectId={??}&versionId={??}&page={??}&size={??}&storedSql={Stored SQL Name}


As shown in the URI the API accepts the following as inputs

Connection Profile Name - A valid TDM connection profile that the user currently logged in should have access to. The DB pointed by this connection profile must be able to execute the Saved SQL specified.

Project Id – The Project ID where the Saved SQL is associated in Datamaker.

Version Id – The Version ID where the Saved SQL is associated in Datamaker.

Page – Specifies the current page number Can be specified as ‘0’.

Size – Specifies number of rows per page.

Stored SQL – The name of the Stored SQL - Case Sensitive.



These Saved SQLs can have variables too and the variables can be substituted from within the JavaScript.


The notation -%(<variableString>)  can be used to create a variable in the saved SQL

Eg: select * from %(schema).PEOPLE


In this example, the various values like, schema, roomType, travelType will be variables.  




This example uses the following saved SQLs:





select distinct P.ID,P.FIRST_NAME from PEOPLE P, ITINERARIES IT where IT.DOM_INTL = '%(travelType)' and P.ID=IT.PEO_ID and exists(select 1 from HOTEL_BOOKINGS HB where room_type='%(roomType)' and HB.ITN_ID=IT.ID)




select distinct room_type ,room_type as description from HOTEL_BOOKINGS HB where HB.ITN_ID in (select id from ITINERARIES where dom_intl='%(travelType)')




select distinct dom_intl as travel_type, case when dom_intl='D' then 'Domestic' else 'International' end as description from %(schema).ITINERARIES


All these SQLs are intended to run in TRAVEL database. In the sample code a connection profile named ‘travel’ is used. 


In this example the Saved SQLs are stored in Project Id 2368 and Version Id 2369.

These numbers can be seen in the JavaScript code and need to be changed accordingly.



Invoke TDM Publish


TDM publish can be invoked by injecting publishService in JavaScript. This service has a method named – publishData which can be used to invoke a publish. This method will accept a JSON object variable with publish payload information. If the payload information is correct, it will invoke the publish.


To obtain the right payload information submit a sample publish from TDM portal and using browser developer tools and construct the payload JSON.

This example invokes a publish based on the following publish information and payload.


Publish from TDM Portal


After Submitting take a look at Developer Tools as shown below.

Note: this is a google chrome browser. But this information can be obtained from any other browser as well.

Construct the payload in JavaScript.

The parameters can be coded to load from variables.


Eg: publishJobPayload.parameters.variableDefaults = [{name: "Pep_Id",  value: $scope.peopleList }];


This takes value from web form “peopleList” is the people id chosen from the Custom SS Tile.

var publishJobPayload = {};

publishJobPayload.name = "Publish From Custom ss Form";

publishJobPayload.description = "Its Cool to Publish from my own ss Form";

publishJobPayload.projectId = "2346";

publishJobPayload.versionId = "2347";

publishJobPayload.type = "PUBLISHJOB";

publishJobPayload.origin = "generation";

var date = new Date();

var seconds = date.getTime();

publishJobPayload.scheduledTime = seconds;

publishJobPayload.email = "";

publishJobPayload.jobs =  [];

publishJobPayload.parameters = {};

publishJobPayload.parameters.variableDefaults = [{name: "Pep_Id",  value: $scope.peopleList }];

publishJobPayload.parameters.generatorId = 2350;

publishJobPayload.parameters.jobType = "PUBLISH";

publishJobPayload.parameters.title = "Publish from Custom SS Form";

publishJobPayload.parameters.publishTo = "TGT";

publishJobPayload.parameters.repeatCount = "1";       

publishJobPayload.parameters.tables =                                               







publishJobPayload.parameters.actionOnDuplicate = "continue";

publishJobPayload.parameters.actionOnGenDuplicate = "remove";

publishJobPayload.parameters.target = "dbo";

publishJobPayload.parameters.dataSourceProfile = "travel";

publishJobPayload.parameters.dataTargetProfile = "travel_e";

publishJobPayload.parameters.email = "";













0 Favorited
1 Files
zip file
TDM_Custom_SS_Tiles_Examples.zip   29K   1 version
Uploaded - 05-29-2019

Tags and Keywords


04-18-2019 11:30 AM

Your welcome Petr.

My answer is no for both of your questions.

I didn't find documentation in Docops. May be there is one within TDM Engg 

04-18-2019 09:53 AM

Hi jeyba01,


Awesome work you did to provide the examples and excellent description of them.

I do have 1 question, is there documentation available for the TDMWeb ?


Any change you attempted to add a password protection in an ARD flow?


Best regards,


03-15-2019 12:46 PM

Thank you for sharing this with the community Badhree!

CA TDM - Custom Self Service Tiles 

Related Entries and Links

No Related Resource entered.