Administration
caCORE SDK 4.2 Data Service Style
 |
 |
 |
 |
Contents |
 |
 |
 |
 |
Obtaining the Data Service Style
The caCORE SDK 4.2 data service style for caGrid 1.3 is provided as an update to the Introduce toolkit. Future versions of caGrid will include this style directly and will not require an update to utilize it.
In the Introduce UI, click Help and choose Introduce Software Update.
 |
Click the button to look for updates, and select the option "Data Services support for caCORE SDK 4.2 (1.3.0.2)" from the tree of available updates.
 |
Click Next to install the style and then Finish to restart Introduce.
Getting Started
The style is invoked when a grid data service is created in Introduce. After the initial service creation screen has been completed, the data service creation dialog will appear. To get started with the style, select "caCORE SDK v 4.2" from the Style drop-down menu.
 |
The Creation Wizard
The caCORE SDK 4.2 style provides a wizard-like interface with multiple steps which prompt the service developer for information required to create and configure the data service to use a caCORE SDK system.
Selecting the caCORE Application API and Client Directory
The first page of the wizard requires the service developer to specify the name of their caCORE SDK generated application and select the appropriate client directory for the API type to be used.
 |
If the local Application Service API will be used, choose the "Local API" radio button and browse to the local-client directory generated by the caCORE SDK project build process. Typically, this will be found at <application-dir>\target\dist\exploded\output\example\package\local-client.
If the remote API is to be used, choose the "Remote API" radio button, and select the remote-client directory for the project. Typically, this will be found at <application-dir>\target\dist\exploded\output\example\package\remote-client. Additionally, the developer must specify the hostname of the machine running the caCORE SDK remote API and the port number on which that service listens. If the remote service uses HTTPS, check the box to use HTTPS for connections.
Click Next: Security to continue.
Specify security options
The next page of the wizard allows the service developer to specify what security options should be used when the data service connects to the caCORE SDK application.
 |
The service developer may optionally specify one of the following types of application service security.
Pass Grid Identity to CSM (Local API Only)
If the service developer selected the Local API on the previous page, an option is available to pass the client's grid identity through to the caCORE SDK Application for authorization against CSM. In this case, the data service must be deployed to a secure container and the service configured to use TLS so that clients connecting to it will have a valid caller identity which can be passed along.
Static Login
The developer may specify a static username and password that will always be used when connecting to the caCORE SDK application service. This login will be used for all connections to the application regardless of caller ID and does not require the data service to be deployed to a secure container. This option is available for both local and remote API interaction with the application service.
Click Next: Domain Model to continue.
Choosing a domain model
The third page of the wizard requires the developer to specify a domain model which will be exposed by the grid data service.
 |
This page gives a choice of three ways to specify the domain model.
MMS
This option will generate a new domain model from the Metadata Model Service (MMS), which in turn may derive metadata from a number of sources, including the caDSR. Click the "Refresh from caDSR Service..." button to load the package and project information available in the caDSR grid service. Once this loads, a Project can be selected via the drop-down menu. Either single packages or all packages in the selected project may be added to the service's domain model by use of the various "Add ..." buttons.
Pre-Generated
This option allows the developer to supply an existing domain model XML document. It will be loaded and its information (name, version, etc) and packages will be displayed.
XMI
This is the most typical and convenient means of supplying a domain model to the grid data service. It can be used to select the XMI file that was used in the creation of the caCORE SDK application, and it will convert the selected XMI model file to a domain model document in addition to importing it to the grid data service. Browse to the XMI document, choose its type (Enterprise Architect or ArgoUML) and enter the values for project short name and version.
 |
Click Next: Schemas to continue.
Mapping Schemas to Packages
The final step in this wizard requires the service developer to map the packages found in the domain model to XML schema.
 |
The table displays each package's name, its current mapping status, and a button to manually map that package to a schema. At the bottom of this page, the button "Automatically Map From SDK Generated Schemas" will attempt to match up each package to a schema found in the caCORE SDK's build artifacts. Since the SDK produces schemas with a 1:1 correspondence to package names, it can do this quickly, saving the developer some time.
Once all packages have been mapped and their status changed to "OK", the "Next" button will change to a "Done" button, indicating the wizard is complete and that the data service is configured and ready to finish generating.