| Oracle® Life Sciences Data Hub Application Developer's Guide Release 2.1.4 Part Number E18306-01 |
|
|
View PDF |
| Oracle® Life Sciences Data Hub Application Developer's Guide Release 2.1.4 Part Number E18306-01 |
|
|
View PDF |
This section contains the following topics:
The Oracle Life Sciences Data Hub (Oracle LSH) includes a set of APIs that enable you to do most of the things you can do through the user interface, including creating, modifying, and installing objects. The APIs are documented in the Oracle Integration Repository at http://irep.oracle.com under Healthcare Suite.
You can call Oracle LSH APIs from source code in a defined Program in Oracle LSH. In this case, no additional security or setup is required.
You can also develop programs that call APIs in a tool outside of Oracle LSH, such as SAS, Oracle SQL Developer, or SQL*Plus, if you have an Oracle LSH database account with certain privileges. You can then see views of all the Oracle LSH data you need, including data from both the LSH (CDR) schema and, for classification data, the TMS schema. You can make the programs you write available to other people from the external tool. See "Calling APIs from Outside the Oracle Life Sciences Data Hub".
Example 1: Using APIs to Perform Multiple Tasks at Once You can write a package that calls multiple APIs to do with one execution what it would take many tasks in the user interface (UI) to do; for example, create a Domain, an Application Area inside the Domain, a Work Area inside the Application Area, and multiple Load Sets, Tables, and Programs, each with a definition in the Application Area and an instance in the Work Area, and install the Work Area. If you have a standard structure for Project/Therapeutic Area Domains, for example, you may want to work this way. However, remember that you can also copy a Domain and all its contents at once in the user interface.
Using APIs is even more attractive when you want to create, for example, multiple objects with variations or large complex objects such as Report Sets. You can create a spreadsheet to store all the variable information and load its data into an Oracle LSH Table instance using a Text Load Set. In your program, use a loop to read all the spreadsheet data and call the relevant Oracle LSH APIs to create the objects.
Example 2: Calling APIs from an External System's UI You may want to allow people in your company to perform actions on Oracle LSH objects from an external system.
For example, instead of requiring that SAS developers check out Source Code in Oracle LSH before opening the SAS IDE from an Oracle LSH Program, you may want to add a button to the SAS user interface that calls the API for checking out the Source Code object when clicked. Then, if the program is located in a schema with Execute privileges on the security API, any user with SAS, a database account in Oracle LSH, and normal Oracle LSH object security privileges on the Source Code definition, can check out the Source Code definition directly from SAS.
Understand Oracle LSH Functionality To use Oracle LSH APIs, you must understand basic Oracle LSH functionality including:
Object Ownership. You must create container objects before creating the objects they contain, because to create any object you must identify its namespace (parent, or container) object. For example, begin by defining a Domain, then an Application Area, then a Work Area, and then create a Table definition in the Application Area and an instance of it in the Work Area (you can use a single API to create both the Table definition and an instance of it); see Appendix A, "Object Ownership".
Installation. You must create an instance of an object definition and install it before you can execute or otherwise use the object.
Mapping. All executable objects must contain at least one Table Descriptor, each of which must be mapped to an installed Table instance; see "Defining and Mapping Table Descriptors".
Checking Objects In and Out. You must check objects out to modify them and check them in before you install and use them; see "Understanding Object Versions and Checkin/Checkout".
Security. All objects require user group assignments to control user access; see "Applying Security to Objects and Outputs".
Classification. To enable objects to appear in the Reports tab of the user interface so that end users can run them and view their outputs, you must classify them. Classifications can also be used in searching for objects; "Classifying Objects and Outputs".
Validation. Objects should be validated according to your company policy whether they are created in the user interface or with APIs; see "Validating Objects and Outputs".
Object-Specific Information. Further information on each object type is included in other chapters of this manual.
Oracle LSH APIs can be grouped into three broad functional categories:
Note:
Additional APIs may become available over time. Refer to
http://irep.oracle.com under Healthcare Suite/Oracle Life Sciences Data Hub for the most current list.Use object APIs to create, modify, check in or out, delete, copy, and move defined Oracle LSH objects. You can also perform object-specific tasks such as installing Work Areas.
APIs are available for the following objects. Where the label in iRep differs from the object name, it is displayed after the object name.
Application Areas
Business Areas
Data Marts
Domains (Life Sciences Data Hub Domain)
Execution Setups
Load Sets (External Data Load Run)
Parameter Sets (Parameter Set)
Parameters (API Parameter)
Planned Outputs (Life Science Data Hub Planned Output)
Programs (Life Sciences Data Hub Program
Report Sets (Report Set)
Source Code (Software Source Code)
Tables, Columns, and Constraints (Meta-Data Registered Data Object)
Variables (Life Science Data Hub Variable)
Work Areas (Application Work Area )
Workflows (Workflow Item)
Workflow Notifications (Workflow Notification)
The following Common Tasks APIs are available (the iRep label is displayed in parentheses):
Applying Version Labels (Life Science Data Hub Generic Object)
Creating Execution Setups (Life Sciences Data Hub Execution Setup Information)
Executing Jobs, Getting Job Information, and Uploading and Downloading LOBs (Life Sciences Data Hub Execution Job)
Mapping Columns (Life Science Data Hub Column Mapping)
Setting up Security (Life Sciences Data Hub Object Security Policy)
Validation (LSH_VALIDATION_FWK). Use this package to change the validation status of user-defined Oracle LSH objects.
Classification Hierarchy Values
Object Classification
Subtype Classification
Notes:
You must create classification hierarchies and levels in the Oracle LSH user interface. You can add terms, or values, using an API.Classifications-related operations use database objects and tables from the TMS schema. The TMS data is available from within the Applications schema through views.
See also "Utility APIs".
This section contains the following topics:
To run any API package from a tool outside of Oracle LSH, such as SAS, SQL Developer, or SQL*Plus, your system administrator needs to do the following:
Set up an Oracle LSH database account linked to your LSH user account; see "Creating Database Accounts" in the Oracle Life Sciences Data Hub System Administrator's Guide.
Grant your Oracle LSH database account Execute privileges on the API security package cdr_pub_api_initialization.
In addition, to run APIs that insert, delete, or modify classification hierarchy terms, you need security access to the Oracle Thesaurus Management System (TMS) instance that is installed as part of Oracle LSH. The Oracle LSH classification system is based on TMS. Ask your system administrator to use the script tmsadduser.sql to do the following:
Create a TMS user account with the same name as your Oracle LSH database account so that your account is entered in the TMS_ACCOUNTS and OPA_ACCOUNTS tables.
Give your TMS user account superuser privileges in the TMS_ACCOUNTS table.
Grant your TMS user account the TMS_MAINTAIN_PRIV database role.
You must call a special security API, cdr_pub_api_initialization, from every program that calls an Oracle LSH API and that you intend to run from outside Oracle LSH. This API contains three functions:
EnableApis
DisableApis
AreApisEnabled
The initialization of almost every API calls the AreApisEnabled function of the security API, cdr_pub_api_initialization, to check if the EnableAPIs flag is set to True in the calling program. If the program does not have EnableAPIs set to True, the initialization fails.
To set the EnableApis flag to True, call the EnableApis function of the same security API from your program. This is possible only from a schema/user account to which a system administrator has explicitly granted the Execute privilege on the cdr_pub_api_initialization API.
Therefore, when you write a program that calls an API and is intended for use outside Oracle LSH, set the EnableApis flag to True in your program and then set it to False at the end to force the security check on the schema the next time the program is run:
Begin the body with the following code to call the function to enable APIs:
call cdr_pub_api_initialization.enableApis (arguments);
The arguments are described in cdr_pub_api_initialization itself.
At the end of the body, disable APIs with the following code:
cdr_pub_api_intialization.disableApis (arguments);
If you need to call multiple APIs from SAS, you may want to use a PL/SQL wrapper around the API calls so that you only call PL/SQL once. For an example of a PL/SQL wrapper, see "Passing Values from a Program Instance to the Report Set for Post-Processing". For another example of calling an Oracle LSH API from SAS, see "Calling an API to Capture Output Parameter Values".
When you develop a program outside Oracle LSH that will call Oracle LSH APIs, you can use your own schema in the external tool (such as SQL*Plus, SQL Developer, or SAS) to run and test the program, if you have Execute privileges on cdr_pub_api_initialization. When you are ready to allow other people to run it, copy it into a different location.
Oracle recommends setting up one or more permanent, publicly available schemas in the Oracle LSH database for the purpose of compiling and storing programs that call Oracle LSH APIs. Grant each schema Execute privileges on cdr_pub_api_initialization. This approach has the following advantages:
If a user manually runs your program, he or she must enter the program location and name explicitly. This will be much easier if the user knows which schema contains such programs.
If you set up the program to run automatically when a user clicks a button in the external system's user interface, for example, you must hardcode the program's name and location into the code.
You can grant Execute on cdr_pub_api_initialization to a controlled number of schemas.
If you develop and run a Program that calls an API within Oracle LSH—that is, in the defined Source Code of a defined Program object—no security is required beyond normal Oracle LSH object security. You do not need Execute privileges on the cdr_pub_api_initialization API, and you do not need to enable APIs in your Program code.
Note:
Within Oracle LSH, the calls to cdr_pub_api_initialization are unnecessary and in fact a program that includes such a call will not compile because the Work Area schema does not have Execute privileges on cdr_pub_api_initialization.You do need to install the Program before you can run it, as you do any defined Program in Oracle LSH.
You can write packages in an Oracle LSH Program that do anything with APIs that you could do in a package outside Oracle LSH. For example, you could create an instance of a Program definition whose Source Code created a Work Area, several Load Sets, and a Program to merge the data, instead of defining the Work Area, Load Sets and Program through the Oracle LSH user interface.
This section contains the following topics:
Views All Oracle LSH views are public and have names that begin with "cdr_". You can see them in SQL Developer or a similar tool, or query for them using the string cdr_
Note:
During its initial development, Oracle LSH was known as CDR. Therefore many internal names contain the stringcdr. Please think of CDR as a synonym for LSH.This section contains the following topics:
To operate on Oracle LSH objects through object APIs, you must identify the objects. Object identification information is stored in two tables in the Oracle LSH database: cdr_namings, which contains one row for each defined Oracle LSH object, and cdr_naming_versions, which contains one row for each version of each defined Oracle LSH object. Information from these two tables is stored in two composite database object types: cdr_naming_version_obj_type and cdr_base_obj_type.
For both the composite object types, the attributes company_id, obj_id, obj_ver, namespace_obj_id, and namespace_obj_ver form a composite primary key. You can refer to any existing object using this primary key.
Parameters of type cdr_naming_version_obj_type are required in APIs for creating and modifying an object.
The attributes of cdr_naming_version_obj_type are:
company_id. To get your company ID, use CDR_PUB_DEF_FACTORY_UTILS.GetCompanyId.
obj_id is the unique ID of the object. Oracle LSH generates this ID when you create a new object.
obj_ver is the object's version number.
Note:
The attributes company_id, obj_id, obj_ver, namespace_obj_id, and namespace_obj_ver together constitute an object's primary key.namespace_obj_id. The unique ID of the object's parent object; for example, a Table instance is always contained in a Work Area, so its namespace_obj_id is the object ID of its Work Area.
namespace_obj_ver. The version number of the object's parent object.
Note:
You can create a child object only in the latest version of its parent object. If you pass a namespace version number that is not the latest when creating a child object, the system ignores the value you pass and creates the child in the latest version of the parent.namespace_start_obj_ver. This attribute contains the version number of the parent object at the time the version represented by obj_ver of the object represented by obj_id was created.
namespace_end_obj_ver. This attribute contains the version number of the parent object at the time when the version represented by obj_ver of the object represented by obj_id was superseded by a higher version. If the object is still the most current version, then this attribute contains the value 999999.
object_type_rc This attribute defines what type of object you are creating or modifying. This value is mandatory for creating objects, but not for modifying objects. See "Retrieving Reference Codelist Names and Values" for information on retrieving valid values.
name. This is the name of the object.
owning_location_rc. This attribute is entered in the system at LSH installation time and is stored as a profile in the system. The system automatically sets this value to the profile value for all objects.
checked_out_flag_rc. This value indicates whether the object is currently checked out or not. The possible values are $YESNO$YES and $YESNO$NO.
checked_out_id is the user ID of the person who checked out the object, if it is currently checked out.
object_subtype_id. This attribute specifies the ID of the object's subtype. Use CDR_PUB_DF_NAMING_UTIL.GetObjectSubtypeID to retrieve an object's subtype ID.
description. This is an optional attribute but it is highly recommended that you provide a description for future reference. You can modify the description using appropriate API for the object.
ref_company_id. If the object is an instance object, this attribute contains the company ID of the source definition.
ref_obj_id. If the object is an instance object, this attribute contains the object ID of the source definition.
ref_obj_ver . If the object is an instance object, this attribute contains the object version number of the source definition.
copied_from_company_id. If the object is a copy of another object, this attribute contains the company ID of the original object.
copied_from_obj_id. If the object is a copy of another object, this attribute contains the object ID of the original object.
copied_from_obj_ver. If the object is a copy of another object, this attribute contains the object version number of the original object.
object_version_number. This attribute is for Oracle LSH internal use only. Never enter a value for this attribute.
status_rc. This attribute contains the current status of the object. See "Retrieving Reference Codelist Names and Values" for information on retrieving valid values.
validation_status_rc. This attribute contains the current validation status of the object. See "Retrieving Reference Codelist Names and Values" for information on retrieving valid values.
version_label. This attribute stores the version label of the object, if any.
For some operations on objects, only the identification contained in a CDR base object type (cdr_base_obj_type) is required. Some APIs allow you to operate on multiple objects at the same time by using a parameter based on a collection of CDR base object types called cdr_base_obj_coll.
A CDR Base Object Type contains a subset of the information contained in a CDR naming Version Object Type (see "CDR Naming Version Object Type").
Each Oracle LSH object type has its own unique attributes beyond what is included in the CDR Naming Version Object Type and CDR Base Object Type. These unique attributes are included in a view for each object type. The view includes information on both definitions and instances of a particular object type. In the case of Tables, it includes Table Descriptors as well as Table definitions and instances.
APIs that are used to create or modify Oracle LSH defined objects contain parameters based on these supplementary database object types. You can set values for the object-specific attributes using these parameters.
For example, the supplementary database object type for Oracle LSH Programs is called cdr_program_obj_type. In the Create Program API, the parameter pi_cdrprgobjtype is of this type. Its attributes are:
company_id. To get your company ID, use CDR_PUB_DEF_FACTORY_UTILS.GetCompanyId.
obj_id. The unique ID of the Program.
obj_ver. The Program's version number.
tech_type_id. Different executable object types have different technology types, which can be queried using the view cdr_tech_types_v. Use the column program_type_rc to see which tech type is valid for a particular object type. In the case of Programs, only the tech types whose value in the program_type_rc column is $PROGRAMTYPES$PROGRAM and which are present in the lookup type cdr_tech_types are allowed. They are: $TECHTYPES$SAS, $TECHTYPES$SASCATALOGS, $TECHTYPES$SASFORMATS, $TECHTYPES$PLSQL, $TECHTYPES$REPORTS.
Note:
Tech types that are not included in the lookup type cdr_tech_types are used internally only and should not be used with public APIs.manual_validation_flag_rc. This flag determines whether a Program's outputs receive their validation status from their Execution Setup or must be validated manually. The valid values are: $YESNO$YES and $YESNO$NO.
See Chapter 5, "Defining Programs" for information about these attributes. Each object type has its own chapter in this manual where its attributes are described.
Utility APIs provide procedures and functions to assist you in writing your Oracle LSH API-based programs.
The following Utility APIs (displayed in iRep under Life Sciences Data Hub Setup Utility) are available:
CDR_PUB_API_INITIALIZATION. You must call this security-related package every time you call any API from outside Oracle LSH; see "Calling the Security API Package" for further information.
CDR_PUB_DEF_FACTORY_VALIDATE. This package includes the following:
ValidateNamespace checks whether an object's parent object is valid, given the child object's company_id, obj_id, and obj_ver.
ValidateReference checks whether an object instance references a valid object definition, given the object instance's company_id, obj_id, and obj_ver.
CDR_PUB_DEF_FACTORY_SUPPORT.GetNamingObject retrieves all the information in a cdr_naming_version_obj_type for an object given its primary key.
CDR_PUB_DEF_FACTORY_UTILS. This package includes the following:
GetCDRBaseObject retrieves an object's namespace object's namespace_object_id , namespace_object_version and object_version_number.
GetCompanyID retrieves the Company ID in your environment. This value was entered when your Oracle LSH instance was installed. It may be the same as your company's Oracle Support Customer ID. For better performance, instead of using GetCompanyID, use CDR_DF_PUB_DEF_CONSTANTS.CURRENT_COMPANY_ID.
CDR_PUB_DF_NAMING_UTIL. This package retrieves information from the CDR Namings table (internally, LSH defined objects are known as "namings"):
IsNamingCheckedOut determines whether or not a given object is currently checked out.
GetChkoutProp retrieves information about the checkout.
GetLastVersion retrieves the most current version of an object.
GetLatestVersionOfParent retrieves the most current version of an object's parent object.
GetNamingVersionObject retrieves all the information in a cdr_naming_version_obj_type for an object given its cdr_base_obj_type.
GetObjectSubtypeID retrieves the subtype ID of a given object.
GetParentNaming retrieves the cdr_base_obj_type information for an object's parent object.
GetRefNaming retrieves the cdr_base_obj_type information for an instance object's definition object.
CDR_PUB_MSG_PUB retrieves all messages generated by APIs in a package. See "Code Example Using Security and Error Message APIs".
CDR_PUB_DEF_CONSTANTS hosts definition constants for Oracle LSH APIs.
CDR_PUB_DF_WORKAREA.CheckInWorkArea This API offers functionality not available in the user interface. It checks in all object instances in a Work Area at the same time. If you are creating a Work Area and multiple object instances in it, this API will save work.
Some database object type attributes (those ending in the string _rc) have a fixed set of allowed values stored in a lookup (reference codelist). These attributes correspond to fields in the user interface with a drop-down or pop-up list of values. To supply or change one of these values you must enter the exact string stored in the reference codelist, with the codelist name surrounded by dollar signs and followed by a codelist value.
For example, the API to create any object includes a parameter of type cdr_naming_version_obj_type, one of whose attributes is object_type_rc. You must enter the correct string for the type of object you want to create.
Reference codelists are stored in a table you access through the view cdr_lookups. The following columns contain the following information:
lookup_type: reference codelist names
lookup_code: reference codelist values
meaning: the text that is displayed in the user interface
description: additional information (sometimes)
If you have LSH Setup Admin privileges you can look up reference codelists in the Applications user interface; see "Querying and Viewing Lookups" in the Oracle Life Sciences Data Hub System Administrator's Guide.
You can browse the view in a tool like SQL Developer to find these values. However, it is not always easy to guess the name of the reference codelist. In that case, you can go into the Oracle LSH user interface to where they are displayed and note one of the allowed values, then query.
For example, object types are displayed in the Add drop-down list in the Work Area Properties screen. You can see that one object type is Business Area, so you can use the following query:
select lookup_type, lookup_code, meaning from cdr_lookups where meaning like '%Business Area%';
Now you know that the lookup_type for object types is CDR_OBJECT_TYPES and you can use the following query to get all the other values:
select distinct lookup_code, meaning from cdr_lookups where lookup_type = 'CDR_OBJECT_TYPES';
While working with classification-related APIs, you may need the domain ID for the Oracle LSH environment you are working in. This is the ID for your Oracle LSH instance, which is created during installation. It has nothing to do with user-defined Domains that contain Application Areas.
Use the following query to find the domain ID of your Oracle LSH environment:
SELECT def_domain_id FROM tms.tms_def_domains WHERE name = 'cdr_user_hier';
There are two utility Oracle LSH APIs that you call in conjunction with other Oracle LSH APIs:
cdr_pub_api_initialization. This API is required for developing and running programs that call any Oracle LSH API from outside Oracle LSH. See "Calling the Security API Package" for further information.
cdr_pub_msg_pub. This API returns error messages from other Oracle LSH APIs called in the same package.
The following code provides an example of calling the API to define a Work Area and each of the utility APIs.
Example 14-1 Program that Calls the API to Define a Work Area and Calls the Security and Error Message APIs
Cdr_Pub_Df_Workarea.createWorkArea (
p_api_version=>1
,p_init_msg_list=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_commit=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_validation_level=>CDR_PUB_DEF_CONSTANTS.G_VALID_LEVEL_FULL
, x_return_status => x_return_status
, x_msg_count => x_msg_count
, x_msg_data => x_msg_data
, pio_sourceCdrNaming =>varWANSObj
, pio_workareaObjType =>varWAObj
, pi_defClassificationColl => NULL
);
IF x_return_status <> 'S' THEN
dbms_output.put_line('Error found in createProgram');
END IF ;
x_msg_count := CDR_PUB_MSG_PUB.COUNT_MSG(
p_api_version=>1
,p_init_msg_list=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_commit=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_validation_level=>CDR_PUB_DEF_CONSTANTS.G_VALID_LEVEL_FULL
);
IF x_msg_count >= 1 THEN
FOR i IN 1..x_msg_count LOOP
IF i =1 THEN
x_msg_data := CDR_PUB_MSG_PUB.GET(
p_api_version=>1
,p_init_msg_list=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_commit=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_validation_level=>CDR_PUB_DEF_CONSTANTS.G_VALID_LEVEL_FULL
,p_msg_index =>CDR_PUB_MSG_PUB.G_FIRST
,p_encoded =>CDR_PUB_DEF_CONSTANTS.G_FALSE);
ELSIF i = x_msg_count THEN
x_msg_data := CDR_PUB_MSG_PUB.GET(
p_api_version=>1
,p_init_msg_list=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_commit=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_validation_level=>CDR_PUB_DEF_CONSTANTS.G_VALID_LEVEL_FULL
,p_msg_index =>CDR_PUB_MSG_PUB.G_LAST
,p_encoded =>CDR_PUB_DEF_CONSTANTS.G_FALSE);
ELSE
x_msg_data := CDR_PUB_MSG_PUB.GET(
p_api_version=>1
,p_init_msg_list=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_commit=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_validation_level=>CDR_PUB_DEF_CONSTANTS.G_VALID_LEVEL_FULL
,p_msg_index =>CDR_PUB_MSG_PUB.G_NEXT
,p_encoded =>CDR_PUB_DEF_CONSTANTS.G_FALSE);
END IF ;
dbms_output.put_line('Message:'||i ||' : '|| x_msg_data);
END LOOP;
END IF;
Cdr_Pub_Api_Initialization.disableAPIs(
p_api_version=>1
,p_init_msg_list=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_commit=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_validation_level=>CDR_PUB_DEF_CONSTANTS.G_VALID_LEVEL_FULL
, x_return_status => x_return_status
, x_msg_count => x_msg_count
, x_msg_data => x_msg_data
);
EXCEPTION
WHEN OTHERS THEN
Cdr_Pub_Api_Initialization.disableAPIs(
p_api_version=>1
,p_init_msg_list=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_commit=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_validation_level=>CDR_PUB_DEF_CONSTANTS.G_VALID_LEVEL_FULL
, x_return_status => x_return_status
, x_msg_count => x_msg_count
, x_msg_data => x_msg_data
);
END my_procedure;
BEGIN -- Package init block
Cdr_Pub_Api_Initialization.enableAPIs(
p_api_version=>1
,p_init_msg_list=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_commit=>CDR_PUB_DEF_CONSTANTS.G_FALSE
,p_validation_level=>CDR_PUB_DEF_CONSTANTS.G_VALID_LEVEL_FULL
, x_return_status => x_return_status
, x_msg_count => x_msg_count
, x_msg_data => x_msg_data
);
END my_package;
|
 Copyright © 2006, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|