----
h1. caCORE SDK 4.2 Data Service Style
----

{cagridtoc:exclude=exclude=caCORE SDK 4.2 Data Service Style}

h1. 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

{attached-image:attachmentname=Select Update.png|tablealign=center}

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.

{attached-image:attachmentname=Update Style.png|tablealign=center}

Click Next to install the style, and then Finish to restart Introduce.

h1. Getting Started
----

The style is invoked when a [grid data service|dataservices:] is created in [Introduce|introduce:Home]. 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.

{attached-image:attachmentname=Step 0.png|tablealign=center}

h1. 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.

h3. 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.

{attached-image:attachmentname=Step 1.png|tablealign=center}

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.

h3. 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.

{attached-image:tablealign=center|attachmentname=Step 2.png}

The service developer may _optionally_ specify one of the following type of application service security.

h5. 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 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.

h5. Static Login

The developer may specify a static username and password which 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.

{attached-image:tablealign=center|attachmentname=Step 3a.png}

This page gives a choice of three ways to specify the domain model.

h5. 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.

h5. 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 displayed.

h5. 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 will convert the selected XMI model file to a domain model document and import 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.

{attached-image:tablealign=center|attachmentname=Step 3b.png}

Click *Next: Schemas* to continue.

h3. 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.

{attached-image:tablealign=center|attachmentname=Step 4.png}

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 fairly 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 the data service is configured and ready to finish generating.