space
Previous Page | Next Page

Model Usage

Usage Scenario: Creating Metadata for a Stored Process


Purpose

This usage scenario describes how to create metadata for a stored process. The scenario includes metadata types from several submodels.

Note:   Developers are discouraged from creating or using stored process metadata with the SAS Open Metadata Interface. Instead, stored processes should be created with the new stored process API com.sas.services.storedprocess.metadata. For more information about this API, see the Java documentation at http://support.sas.com/rnd/gendoc/bi/api/index.html.


Requirements

This usage scenario assumes that the user has a general understanding of the Software Deployment Submodel, the Transform Submodel, and the Prompt Submodel of the SAS Metadata Model.


Description of a Stored Process

A stored process is a SAS program that is stored on a server. It can be executed as requested by client applications. Stored processes are defined by metadata objects that have the information required to run the process. This includes information about where the process can be run, the code that should be run, parameters that need to be specified by a user or another process, the physical inputs to the process, and the outputs of the process.


How to Define a Stored Process

In this scenario, the Product Sales Demo is defined. Central to defining a stored process is the ClassifierMap metadata type. ClassifierMap is a subtype of the Transformation metadata type. It is used to show the flow of data through a process. ClassifierMap has properties that an application needs to determine what the process is and how to run it. ClassifierMap is differentiated from other Transformation types by the ClassifierSources and ClassifierTargets associations. Classifier and its subtypes represent data in the SAS Metadata Model and can have features. For example, The PhysicalTable metadata type is a subtype of Classifier that has features called Columns. The stored process that represents the Product Sales Demo consists of stored SAS code, which runs against a SAS data set to produce a sales report. The SAS code is associated to the ClassifierMap with the SourceCode association (numbered 2 in Figure 1). Source code can be stored in a subtype of the Text metadata type, including TextStore (used for source code stored in the SAS Metadata Repository), Document (a URI to an external document), SASCatalogEntry, ArchiveFile (zip file), or File. In this scenario, the source code is stored in a file named PrdSale.sas. The File object that represents it has a Directories association (numbered 3) to a Directory object that describes the location of the file.

It is important to know where the stored process can run, which logical server to use, and how to access the logical server. The ComputeLocations association (numbered 1) lists the LogicalServer objects that can be used to run the stored process. In this scenario, the LogicalServer object describes a SAS Workspace Server, because SAS is necessary to run the SAS code.

[The metadata objects used to describe a stored process for the Product Sales Demo.]

Figure 1. The metadata objects used to describe a stored process for the Product Sales Demo.

The SAS Workspace Server is defined, in part, using the LogicalServer metadata type. See Figure 2 and Usage Scenario: Creating Metadata for a SAS Workspace Server to learn about additional information that might be needed about how to access this component. LogicalServer has a UsingComponents association (numbered 4 in Figure 2) to a ServerComponent object. ServerComponent has a SourceConnections association (numbered 2) to a TCPIPConnection object. TCPIPConnection has the information for the stored process to connect to the SAS Workspace Server. It also has information about the authentication domain for the SAS Workspace Server. TCPIPConnection has a Domain association (numbered 5) with the AuthenticationDomain metadata object.

In addition, the SAS Workspace Server LogicalServer object has a UsedByComponents association (numbered 3) to a ServerContext object. ServerContext has associations to the data packages that are accessible by this server. In this example, two objects have a DataPackages association to the SAS Workspace Server: a Directory object and a SASLibrary object. When a SAS library is defined, often the directory information is also defined. A Directory object has a UsingPackages association (numbered 6) with a SASLibrary object. SAS Management Console supports creating library definitions. For more information, see Usage Scenario: Creating Metadata for a SAS Library.

[The metadata objects that describe a SAS Workspace Server using LogicalServer.]

Figure 2. The metadata objects that describe a SAS Workspace Server using LogicalServer.

Information about the inputs (ClassifierSources) and outputs (ClassifierTargets) is needed next. Only metadata types that inherit from the Classifier metadata type can be part of these associations. Generally, metadata types that are classifiers represent objects that have structure. Examples of classifiers are data tables and cubes. The input and output information can be embedded in the source code. However, even if information is embedded in the source code, it should be documented as part of this process to facilitate impact analysis. If a classifier source is changed or moved, it is helpful to know all of the stored processes that might be affected by the change or move. Beginning in SAS 9.2, input and output information, as well as information internal to the stored process, can be stored in a TextStore object with the Notes association (numbered 3 in Figure 3). Some of this information is part of the associated prompts.

In this scenario, a SAS data set named Product Sales is the only source. It has a ClassifierSources association (numbered 1). The SAS data set is represented by the PhysicalTable metadata type and has a TablePackages association (numbered 2) to a SASLibrary object to locate the data set. This library is known to the SAS Workspace Server where the process is run.

The output is not explicitly modeled in this example. Instead, information about the output is stored in the associated TextStore object.

[The metadata objects that create an output.]

Figure 3. The metadata objects that create an output.

This stored process requires a user to submit two parameters. These parameters are defined using Prompt objects referenced by a PromptGroup object. The PromptGroup object has a Prompts association (numbered 1 in Figure 4) to the ClassifierMap object. It has a ReferencedPrompts association (numbered 2) to the Prompt objects. Each Prompt object represents one of the required parameters for the stored process to run. For more information about Prompt objects, see the SAS 9.2 Stored Processes: Developer's Guide.

[The metadata objects that describe the input parameters.]

Figure 4. The metadata objects that describe the input parameters.

space
Previous Page | Next Page | Top of Page