| Oracle® Study, Subject, and Visit Synchronization Integration Pack for Siebel Clinical and Oracle Clinical Implementation Guide Release 11.1 E36156-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Study, Subject, and Visit Synchronization Integration Pack for Siebel Clinical and Oracle Clinical Implementation Guide Release 11.1 E36156-01 |
|
|
PDF · Mobi · ePub |
This chapter discusses:
This section discusses the following:
Section 5.1.1, "Prerequisites for Synchronizing Clinical Study Sites"
Section 5.1.2, "Prerequisites for Synchronizing Clinical Study Subject"
In Oracle Clinical, the state and country values for the site address should be a valid region defined in the system. Siebel Clinical provides a list of values for states and countries that can be customized by each company. You must populate the State and Country Domain Value Map (DVM) before the integration can be used.
For more information about DVMs, see Section 5.5.
In addition to populating the DVM, there may be states and countries available in Siebel Clinical that are not recognized as regions in Oracle Clinical. Scripts have been provided to help you identify the missing regions. Run these scripts and compare the output. Enter any missing states or countries into Oracle Clinical as regions.
Note:
While Oracle Clinical permits a hierarchy of regions, Siebel Clinical does not. You must enter states as regions within the country region in OC for this integration.Perform the following steps to download a list of States and Countries in Oracle Clinical:
Log in to the Fusion Middleware Server and change the directory to the following location under the AIA Home:
$AIA_HOME/data/StudySubjectVisitSyncSCandOC/sql
Log in to SQL*PLUS as rxa_des user.
SQL*PLUS > start OracleClinicalRegionDataDownload.sql.
SQL*PLUS > exit.
Verify the list of states and countries in the OracleClinicalRegionDataDownload.out file.
Perform the following steps to download a list of States and Countries in Siebel Clinical: For Oracle Database:
Log in to the Fusion Middleware Server and change the directory to the following location under the AIA Home:
$AIA_HOME/data/StudySubjectVisitSyncSCandOC/sql
Log in to SQL*PLUS as Siebel table owner.
SQL*PLUS > start SiebelClinicalRegionDataDownload.sql.
SQL*PLUS > exit.
Verify the list of states and countries in the SiebelClinicalRegionDataDownload.out file.
Perform the following steps to run the script:
Ensure that the MS SQL server client is installed in the user machine.
Create a system DSN for the database connection to the Siebel database.
Open the MS SQL server client and log in to the database by using the System DSN created in the previous step.
Run the SQL script file - SiebelClinicalRegionDataDownload.sql.
The output file format is as follows:
Region Code~Name~Description~Region Type Code ASIA~ASIA~ASIA continent~CONT EUROPE~Europe~Europe~CONT DE~Germany~Germany~COUNTRY IND~INDIA~INDIA~COUNTRY
You must perform the following task for updates of the Protocol Site to come over from Siebel Clinical to Oracle Clinical:
Navigate to Admin > Server Management.
Click Tasks.
Query for Workflow Monitor Agent.
Set the ActionInterval parameter to any number less than 120 (for example, 5).
You must populate the ClinicalStudySubjectStatus DVM.
For more information about DVMs, see Section 5.5.
You must define clinical items for each activity and visit in the active Subject Visit Templates in Siebel Clinical.
For more information about defining clinical items in Siebel Clinical, see the Siebel Life Sciences Guide, Version 8.1, Rev. D.
In Oracle Clinical, the study must have the Subject Activity integration enabled.
You must enter each Clinical Item as an Activity in the Maintain Activity Completion Criteria form and the completion criteria defined for it.
You must schedule the Track Activities batch job to run on a regular basis.
For more information about Oracle Clinical prerequisites, see Section 5.3.
Data requirements indicate the mandatory data that must be provided to make the integration flows successful.
This section discusses the following process integrations:
Section 5.2.1, "Data Requirements for Synchronizing Clinical Study Sites"
Section 5.2.2, "Data Requirements for Synchronizing Clinical Study Subject Information"
The following protocol site information is required for the integration to successfully create and update a Study Site in Oracle Clinical:
A primary address must be defined for the Protocol Site. The primary address must include the following defined values:
Address Line
City
State
Zip Code
Country
Phone
Each principal investigator assigned to a protocol site must have these defined values:
First Name
Last Name
Phone Number
The patient position enrollment date in Oracle Clinical must be populated for a subject to be assigned an Enrollment Visit Template in Siebel Clinical.
For more information about defining clinical items in Siebel Clinical, see the Siebel Life Sciences Guide, Version 8.1, Rev. D.
For more information about mapping activity completion criteria in Oracle Clinical, see Section 5.3.2.4.3.
This section discusses:
This section describes the tasks and general procedures that you must complete to integrate a Siebel Clinical protocol with an Oracle Clinical study.
For more information about configuring Siebel Clinical for integration with Oracle Clinical, see the Siebel Life Sciences Guide, Version 8.1, Rev. D.
Study site information is entered as a Protocol Site in Siebel Clinical and is used to create a Study Site in Oracle Clinical. This integration is unidirectional, from Siebel Clinical to Oracle Clinical.
For Study Sites to be synchronized between Siebel Clinical and Oracle Clinical, you must assign the CDMS Study ID for the protocol and select the Synchronize Active Sites check box. When the Siebel Clinical Protocol Site is ready to be synchronized with the associated Oracle Clinical study, you must select a primary address from the list of Protocol Site addresses and select the Activate Synchronization check box. When this is complete, the Oracle Clinical study and the Siebel Clinical protocol are linked and the first Siebel Clinical protocol site is associated with a newly created study site in Oracle Clinical.
When the Activate for Synchronization flag is selected for a Protocol Site in Siebel Clinical, a Study Site is created in Oracle Clinical. If the principal investigator responsible for the protocol site does not exist in Oracle Clinical, one is created.
The combination of the primary address of the protocol site and the account are considered as a Site in Oracle Clinical. If this combination does not exist, a new site is created in Oracle Clinical.
Updates to the investigator, site, or study site in Siebel Clinical are synchronized to Oracle Clinical. Updates made in Oracle Clinical for investigator, site, or study site are not synchronized back to Siebel Clinical. Deletion of a principal investigator account or protocol site in Siebel Clinical will not result in deletion of any objects in Oracle Clinical.
For more information about configuring Siebel Clinical for integration with Oracle Clinical, see the Siebel Life Sciences Guide, Version 8.1, Rev. D. For more information about configuring relevant integration components, see Chapter 2.
After you have enabled Patient Integration for an Oracle Clinical study, the synchronization process for patient information can be initiated. In Oracle Clinical, patient positions are created for the target enrollment of a study and assigned to study sites based on the target enrollment for the study site. If the enrollment date is entered for a patient position, it indicates that a patient has been enrolled in the study and assigned an Enrollment ID. This creates a subject for the appropriate Protocol Site in Siebel Clinical and the active Enrollment Visit Template to be assigned to the subject.
If data is collected for a patient position in Oracle Clinical or OCRDC, and no enrollment date has been specified, the system assumes this to be a patient undergoing the screening process and assigns a Screening ID. This creates a subject for the appropriate Protocol Site in Siebel Clinical and assigns the active Screening Visit Template to it.
Although Siebel Clinical requires the subject's initials and birth date to create a subject, this information is not mandatory in Oracle Clinical. If the patient's initials are not entered in Oracle Clinical, the Enrollment ID is used as the initials in Siebel Clinical. If the patient's birth date is not entered in Oracle Clinical, the birth date is set to Jan 1, 1800 in Siebel Clinical. This is an invalid date that can be used to identify subjects whose information should be updated. You can then manually correct the data in Siebel Clinical.
The Informed Consent Date is not collected in Oracle Clinical. Therefore, subjects that are created in Siebel Clinical by the integration will have the Informed Consent Date set to the birth date of the subject. This will alter the dates in the Visit Schedule for the subject and should be manually corrected in Siebel Clinical.
When Siebel Clinical assigns a Screening Visit Template to a subject, the screen date is required. This is not a required field in Oracle Clinical. Therefore, if this date is not collected for a subject in Oracle Clinical, the system populates a default value of Jan 1, 1900. This will impact the dates in the Visit Schedule for the subject and should be manually corrected in Siebel Clinical.
For more information about synchronization, see Section 1.3.2 and Chapter 3.
In Siebel Clinical, activities are scheduled to occur at patient visits. The patient visit itself is considered an activity. Based on completion criteria you have defined for an activity or visit, the data in Oracle Clinical can be used to send information about the status of an activity to Siebel Clinical. Completion criteria are defined by indicating which visit, DCIs, DCMs, or DCM questions in Oracle Clinical must be completed for the associated activity or visit to be considered complete.
Clinical Items
In Siebel Clinical, Subject Visit Templates are defined for screening and enrollment visits. When protocols are amended, new versions of Subject Visit Templates are created and activated. Although the same activity may occur at different visits in a Subject Visit Template or across different versions of a visit template, Siebel Clinical considers each activity as a separate entity.
To minimize the effort involved in defining the same completion criteria for the same activity multiple times, the concept of a clinical item has been introduced in Siebel Clinical. When a new activity is added to a Subject Visit Template, by default, the system sets the clinical item to the activity description.
Visits are also considered as activities. When a new visit is added to a Subject Visit Template, the clinical item defaults to the visit name.
If a visit has the same completion criteria as that of a visit in another version or in an entirely different Subject Visit Template, the visits can be assigned to the same Clinical Item. This lets the completion criteria to be specified once in Oracle Clinical. However, the same clinical item cannot be added to more than one visit in the same Subject Visit Template version.
An example of this is a Screening Visit Template comprising of two visits, Visit 1 and Visit 2. If a protocol amendment changes Visit 2, a new version of the Screening Visit Template is created. You can create a clinical item value that is assigned to Visit 1 in both versions of the Screening Visit Template.
If a Subject Visit activity occurs at multiple visits or in multiple Subject Visit Templates or Subject Visit Template versions, the same clinical item can be assigned to that set of activities. For example, a clinical item can be assigned to the set of identical lab tests that are performed at each of the visits. This enables the completion criteria for that activity to be defined once in Oracle Clinical against a single clinical item.
For more information on defining clinical items, see Siebel Life Sciences Guide, Version 8.1, Rev. D.
In Siebel Clinical, when the Activate for Synchronization field is selected for a Protocol Site, a corresponding Study Site is created in Oracle Clinical. A study site in Oracle Clinical cannot exist without Investigator and Site details. If the corresponding information is not available in Siebel Clinical, it will be created in Oracle Clinical. These new objects are used to create the Study Site in Oracle Clinical. All sites and investigators transferred by the integration are created as active.
In Oracle Clinical, any updates made to a site or an investigator associated with an integrated study may be overwritten by updates from Siebel Clinical.
Oracle recommends you to modify the PL/SQL procedure, LocalStudySite.ChangeStudySite, to prevent study sites created by user, RXA_WS, from being updated. This prevents someone in Oracle Clinical from breaking the link between Protocol Site in Siebel Clinical and Study Site in Oracle Clinical.
Oracle Clinical has new options that facilitate the integration with Siebel Clinical. One option enables the transfer of patient_position information once the enrollment date has been entered or data has been entered against a patient position without an enrollment date. The other option permits completion criteria for Siebel Clinical activities to be defined in Oracle Clinical and send messages when those activities have been completed.
The following are new settings:
Enable Patient Integration - When this is set to Y, and the enrollment date is entered, or data is entered for a patient position with no enrollment date, messages about patient_positions, patient_status, and the study sites assignments for the patient _positions are written to an Advanced Queue. All subsequent updates to these patient positions are sent to Siebel Clinical.
Enable Subject Activity Integration - When this is set to Y, you will be able to define completion criteria for visits and activities in Siebel Clinical and schedule jobs to send messages to Siebel Clinical when the activities have been completed.
The following sections describe how to set these integrations at the database or study level:
To enable integration at the database level for all new studies, navigate to Admin > Integration Database Settings.
The system displays the Integration Database Settings window. There are two integration settings available:
Enable Patient Integration
Enable Subject Activity Integration
For each setting the default value is N, which indicates that the integration is turned off. If you want to enable one or both of these integrations on all new studies, change the settings to Y and all new studies will be created with the corresponding integrations enabled.
Note:
Changing these settings will not affect any existing studies.If you want to enable the integration only for a few studies, proceed to the study level settings described in the following section.
To enable integration at the study level for an individual study, navigate to Design > Integration Study Settings. The system displays the Integration Study Settings window and specifies the active study. At the database level, there are two integration settings available:
Enable Patient Integration
Enable Subject Activity Integration
The default values for these settings are based on the value of the database level setting defined in Admin > Integration Database Settings form at the time the study was created.
To enable the relevant integration for the study, change the value from N to Y.
Note:
Both the Patient Integration and the Subject Activity Integration must be enabled to use the Subject Activity integration.Enrollment Date and Informed Consent Date
Siebel Clinical requires an enrollment date to be specified for enrolled patients. If you use the CRF data entry instead of the Patient Positions form to capture this value, you can use the pat_sync function in a derivation procedure to populate the enrollment date in the Patient Positions table. You can also use pat_sync to enter the Informed Consent Date of a patient.
For more information about patient synchronization, see Oracle Clinical Documentation, "Creating a Study."
The Track Activity process is a PSUB batch job, which evaluates all activity completion criteria and determines if the patient data entered or updated since the last time the track activity job was run will cause the completion status or date of an activity or visit to change. If new activity completion criteria have become active since the last time the track activity job was run, all existing patient data for the study is examined.
To run the Track Activity process, navigate to Conduct > Data Validation > Track Activities. The system displays the Track Activity Completion window.
If no study context exists when the Track Activities menu is selected, the system prompts you to select a new study.
When you select the Track Activities menu item, if the study in context is not enabled for Subject Activity integration, the system displays an error and prompts you to select a new study.
If you want to change the study context while in the Track Activities window, select Special > Click Study or Change Study.
For more information about running, viewing, and scheduling PSUB jobs, see Oracle® Clinical Conducting a Study Guide.
The following parameters define how the system will process completion criteria objects.
Completeness Criteria
A Received DCI (RDCI) or Received DCM (RDCM) that is marked blank is not considered complete.
If the study requires two passes, only an RDCI or RDCM, with the status PASS 2 COMPLETE or BATCH LOADED is considered complete.
If the study does not require two passes, only a RDCI or RDCM, with the status PASS 1 COMPLETE, PASS 2 STARTED, PASS 2 PENDING, PASS 2 COMPLETE or BATCH LOADED is considered complete.
An activity will no longer be considered as complete if:
A DCI or DCM that was mapped to an activity is soft deleted.
The blank flag is set to Y for a DCI or DCM that was mapped to an activity.
A response value for a DCM question that was mapped to an activity is modified to a value other than the one defined in the mapping.
A response value for a DCM question that was mapped to an activity is removed leaving the response empty.
If the activity is no longer considered complete due to one of the preceding events, the following information is written to the database queue:
Activity ID (Note that this is the clinical item that is selected for the Activity name in the Map Activities form)
Study
Study Site Code
Patient
Visit (Note that this is the clinical item mapped to the Visit)
Activity Code (can be VISIT or ACTIVITY)
Blank value for Completed Date
If the patient key is changed for a RDCI or RDCM that was mapped to an activity, the activity is no longer considered complete for the old patient.
If the DCI book for an RDCI is either mapped to a DCI Book Visit or contains a RDCM or response mapped to a DCI Book Visit, the activity is no longer considered complete for the mapped visit.
If the visit for a RDCI is either mapped to an activity or contains a RDCM or response mapped to an activity, the activity is no longer considered complete for the old visit.
If the completed date for an activity has changed since the last time the process was run, the following information is written to the database queue:
Activity ID (Note that this is the clinical item that is selected for the Activity name in the Map Activities form)
Study
Study Site Code
Patient
Visit (Note that this is the clinical item mapped to the Visit)
Activity Code (can be VISIT or ACTIVITY)
Completed Date
Oracle Clinical provides the means to map Siebel Clinical activities to Oracle Clinical study definition objects. The purpose of this portion of the integration is to let events in Oracle Clinical - collection of specific data - to trigger the completion of associated activities in Siebel Clinical.
For more information about defining activity completion criteria, see Oracle Clinical Creating a Study.
Cross-references map and connect the records within the application network, and enable these applications to communicate in the same language. The integration server stores the relationship in a persistent way so that others can refer to it.
For more information about cross-references, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite, "Working with Cross References".
The following are the cross-references for Siebel Clinical to Oracle Clinical:
Table 5-1 Cross-references for Siebel Clinical to Oracle Clinical
| REFTABLENAME | COLUMN NAME | DESCRIPTION | USAGE |
|---|---|---|---|
|
CLINICALSTUDYSITE |
COMMON |
Concatenation of row ID of Account and row id of Primary Address for the Protocol Site in Siebel Clinical |
Populated when a Site is created in Oracle Clinical during the Study Site integration. |
|
- |
SEBLCLIN_01 |
Concatenation of row ID of Account and row ID of Primary Address for the Protocol Site in Siebel Clinical |
- |
|
- |
OC_O1 |
Concatenation of Site ID and Site (user identifier) from Oracle Clinical |
- |
|
CLINICALSTUDYINVESTIGATOR |
COMMON |
Row ID for contact in Siebel Clinical |
Populated when an Investigator is created in Oracle Clinical during the Study Site integration |
|
- |
SEBLCLIN_01 |
Row ID for contact in Siebel Clinical |
- |
|
- |
OC_O1 |
Concatenation of Investigator ID and Investigator (user identifier) in Oracle Clinical |
- |
|
CLINICALSTUDYSTUDYSITE |
COMMON |
Concatenation of CDMS_STUDY_ID from Protocol in Siebel Clinical and Protocol Site Number |
Populated when Study Site is created during Study Site integration. |
|
- |
SEBLCLIN_01 |
Protocol Site Id from Protocol Site in Siebel Clinical |
- |
|
- |
OC_01 |
Concatenation of Clinical Study ID and Site ID in Oracle Clinical |
- |
The following are the cross-references for Oracle Clinical to Siebel Clinical:
Table 5-2 Cross-references for Oracle Clinical to Siebel Clinical
| REFTABLENAME | COLUMN NAME | DESCR | USAGE |
|---|---|---|---|
|
CLINICALSTUDYSTUDYSITE |
COMMON |
Concatenation of CDMS_STUDY_ID from Protocol in Siebel Clinical and Protocol Site Number |
Used to look up Siebel Clinical Study Site when subjects are created during the Subject Integration. |
|
- |
SEBLCLIN_01 |
Protocol Site ID from Protocol Site in Siebel Clinical |
- |
|
- |
OC_01 |
Concatenation of Clinical Study ID and Site ID in Oracle Clinical |
- |
|
CLINICALSTUDY_CLINICALSTUDYSUBJECTID |
COMMON |
Concatenation of Clinical Study Code (Study) and Patient Position Code (Patient) from Oracle Clinical |
Populated when subjects are created during the Subject integration. |
|
- |
SEBLCLIN_01 |
Row id of the Subject in Siebel Clinical |
- |
|
- |
OC_01 |
Patient Position ID for Patient Position in Oracle Clinical |
- |
Domain value maps (DVMs) are a standard feature of the Oracle SOA suite, which enables you to equate lookup codes and other static values across applications. For example, "FOOT" and "FT" or "US" and "USA."
DVMs are static in nature, though administrators can add and update additional maps as needed. Transactional business processes never update DVMs, they only read from them.
The following are the DVMs for Study, Subject, and Visit Synch: Siebel Clinical and Oracle Clinical PIP:
Table 5-3 DVMs for Study, Subject and Visit Synch: Siebel Clinical and Oracle Clinical PIP
| DVM Type | DVM Column Name | Comments |
|---|---|---|
|
COUNTRY |
COMMON, SEBLCLIN_01, OC_O1 |
This maps the country codes between Siebel Clinical and Oracle Clinical. |
|
STATE |
COMMON, SEBLCLIN_01, OC_O1 |
This maps the state codes between Siebel Clinical and Oracle Clinical. |
|
CLINICALSTUDYSUBJECT_STATUS |
COMMON, SEBLCLIN_01, OC_01 |
This maps the patient status defined by customers in Oracle Clinical to the Subject status in Siebel Clinical. |
For more information about working with DVMs, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite 11g Release 1, "Working with Domain Value Maps" and "Using Oracle SOA Composer with Domain Value Maps".
To configure email notification, see Oracle® Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack, Setting Up Error Handling.
This integration lets you call external web services from all the ABCS services.
Figure 5-1 shows various invocation points for external web services from a Requester ABCS - UpdateClinicalStudySEBLHealthSciencesReqABCSImpl or UpdateClinicalStudyOCHealthSciencesReqABCSImpl.
Figure 5-1 Calling Web Services From Requester ABCS
Figure 5-2 shows invocation points for external web services for Provider ABCS - UpdateClinicalStudyOCHealthSciencesProvABCSImpl or UpdateClinicalStudySEBLHealthSciencesProvABCSImpl.
Figure 5-2 Calling Web Services From Provider ABCS
To invoke an external web service in an ABCS, perform the following:
Open <AIA_HOME>/aia_instances/<instance_name>/AIAMetaData/config/AIAConfigurationProperties.xml.
Locate the ServiceConfiguration section of the ABCS that is being extended.
For example, if you want Siebel Requester ABCS to call an external web service, go to Service Configuration with service name as {http://xmlns.oracle.com/ABCSImpl/SiebelClinical/Core/UpdateClinicalStudySEBLHealthSciencesReqABCSImpl/V1}UpdateClinicalStudySEBLHealthSciencesReqABCSImpl.
Based on your requirement for control logic, set one of the following extension points to True.
In a requester ABCS, enable one of the following:
PreXformABMtoEBM - Invokes an external web service before ABM to EBM transformation.
PreInvokeEBS - Invokes an external web service before invoking EBS.
In a provider ABCS, enable one of the following:
PreXformEBMtoABM - Invokes an external web service before EBM to ABM transformation.
PreInvokeABS - Invokes an external web service before invoking Application Business Service (ABS).
PostInvokeABS - Invokes an external web service after invoking ABS.
Save AIAConfigurationProperties.xml.
Upload it to the MDS using the following steps:
Navigate to the $AIA_INSTANCE/config directory.
Copy UpdateMetaDataDp.xml to a backup file.
Edit UpdateMetaDataDp.xml file as follows:
<?xml version="1.0" standalone="yes"?><DeploymentPlan component="Metadata" version="3.0"><Configurations><UpdateMetadata wlserver="fp"><fileset dir="${AIA_INSTANCE}/AIAMetaData"><include name="config/AIAConfigurationProperties.xml"/></fileset></UpdateMetadata></Configurations></DeploymentPlan>
Navigate to the $AIA_INSTANCE/bin directory.
Execute the following commands:
For Windows: execute aiaenv.bat
ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml
For Linux: source aiaenv.sh
ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml
Wait till you see a build successful result.
Open the extension service concrete WSDL for the ABCS that is being extended. For example, if Siebel Requester ABCS is being extended to call an external web service, open the file <AIA_HOME>/AIAMetaData/AIAComponents/ExtensionServiceLibrary/SiebelClinical/UpdateClinicalStudySEBLHealthSciencesReqABCSImplExtensionConcrete.wsdl.
Locate the soap:address section of the WSDL towards the end of the file.
Replace the Mirror Servlet location (http://soaserverhost:soaserverport/MirrorServlet/mirror) with the actual web service endpoint.
Save the concrete WSDL.
Upload it to the MDS using the following steps:
Navigate to the $AIA_INSTANCE/config directory.
Copy UpdateMetaDataDp.xml to a backup file.
Edit UpdateMetaDataDp.xml file as follows:
<?xml version="1.0" standalone="yes"?>
<DeploymentPlan component="Metadata" version="3.0">
<Configurations>
<UpdateMetadata wlserver="fp">
<fileset dir="${AIA_HOME}/AIAMetaData">
<include name="AIAComponents/ExtensionServiceLibrary/SiebelClinical/UpdateClinicalStudySEBLHealthSciencesReqABCSImplExtensionConcrete.wsdl"/>
</fileset>
</UpdateMetadata>
</Configurations>
</DeploymentPlan>
Navigate to the $AIA_INSTANCE/bin directory.
Execute the following commands:
For Windows: execute aiaenv.bat
ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml
For Linux: source aiaenv.sh
ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml
Wait till you see a build successful result.
To add custom transformation on fields that are already mapped and transformed in the PIP, you must first identify the transformation that must be extended and customized. You can use custom transformation constructs to enable or disable the custom transformations based on properties in the AIAConfigurationProperties.xml file. You can also use this file to define the custom transformations.
This section discusses the following
Section 5.7.2.2.1, "Adding Custom Transformations - An Example"
Section 5.7.2.2.2, "Uploading AIAConfigurationProperties.xml to MDS"
Section 5.7.2.2.3, "Deploying OC Provider Changes to Server"
SC-OC integration does not let custom transformations be added to the field already mapped in the core transformation xsl file. There are some fields such as, investigator address which are mapped to be blank in the core xsl. There can be scenario where you want to put the site address as the investigator address in OC. To do this, you need to customize the transformation.
As an example, you can extend OC Investigator EBM to ABM Transformation and add custom transformation in the CreateInvestigator flow. The following figure displays the existing elements in this flow as delivered by the integration and the additional constructs. This diagram is a snapshot of the OCProvider.bpel file in Oracle JDeveloper.
To invoke the custom transformation, you must set the property in AIAConfigurationProperties.xml. In the above example, the following properties have been added:
| Properties | Enables custom transformations to... |
|---|---|
|
CustomXForm.InvestigatorABM |
Investigator ABM (Figure 5-3) |
|
CustomXForm.SiteABM |
Site ABM (Figure 5-4) |
|
CustomXForm.StudySiteABM |
Study Site ABM (Figure 5-5) |
Check if the properties in the Table 5–4 are present in the AIAConfigurationProperties.xml file. If not, add these properties at the end of the Service Configuration section of OCProvider in the AIAConfigurationProperties.xml file as shown in the following sample code.
Note:
These properties are not present in the AIAConfigurationProperties.xml file when you upgrade from release 3.1 to 11.1.
<ServiceConfiguration serviceName="{http://xmlns.oracle.com/ABCSImpl/OracleClinical/Industry/HealthSciences/UpdateClinicalStudyOCHealthSciencesProvABCSImpl/V1}UpdateClinicalStudyOCHealthSciencesProvABCSImpl"><Property name="CustomXForm.InvestigatorABM">false</Property><Property name="CustomXForm.SiteABM">false</Property><Property name="CustomXForm.StudySiteABM">false</Property></ServiceConfiguration>
Add the actual transformations to the following six transformation files for the respective ABMs:
Custom_xForm_CreateInvestigatorABM.xsl
Custom_xForm_CreateStudySiteABM.xsl
Custom_xForm_UpdateInvestigtorABM.xsl
Custom_xForm_UpdateSiteABM.xsl
Custom_xFrom_CreateSiteABM.xsl
Custom_xFrom_UpdateStudySiteABM.xsl
To add a custom transformation for Investigator address line 1 field, and map Study Site address line 1 to Investigator address line1 field, you have to modify the Create and Update Investigator custom xsl. Perform the following steps:
In the AIAConfigurationProperties.xml file, set the value of CustomXForm.InvestigatorABM to true.
Upload the updated AIAConfigurationProperties.xml file to MDS. For more information, see Section 5.7.2.2.2.
To modify the Create Investigator transformation, open the Custom_xForm_CreateInvestigatorABM.xsl file.
Figure 5-6 displays the Custom_xForm_CreateInvestigatorABM.xsl file.
Figure 5-6 The Custom_xForm_CreateInvestigatorABM.xsl File
By default, there are no mappings defined in this file.
Perform the following steps to create a copy of the Target Investigator ABM:
Right-click on the transformation file middle pane and choose Auto Map Preferences. The Auto Map Preferences screen is displayed.
Ensure that the following options are selected:
Match Elements with Similar Names
Match Elements Considering their Ancestor Names
For all optional node
Enable Auto Map
Figure 5-7 displays the Auto Map Preferences dialog box with the selected options.
Figure 5-7 Auto Map Preferences Dialog Box
Map the studysite:createInvestigatorElement in the source to studysite:createInvestigatorElement in the target as displayed in the following figures:
Figure 5-8 Mapping studysite:createInvestigatorElement
Figure 5-9 Mapping studysite:createInvestigatorElement
Perform the following steps to add the custom mapping to override the mapping for addressLine1:
Expand the nodes on both source and target.
Right-click and select Delete to delete the mapping for addressLine1 field as shown in the Figure 5-10:
Delete mapping for corresponding xsi:nil attribute and the additional if node for that xsi:nil attribute.
To map the StudySite Address to the Investigator Address, in the source, navigate to following location, and map it to studysite:addressLine1 in the target schema:
$UpdateClinicalStudyReqMsg.UpdateClinicalStudy/ns0:UpdateClinicalStudyEBM/ns0:DataArea/ns0:UpdateClinicalStudy/ns0:ClinicalStudySite/ns0:ClinicalStudySiteLocation/corecom:LocationReference/corecom:Address/corecom:LineOne
Figure 5-12 displays the result.
Figure 5-12 Mapping StudySite Address to Investigator Address
Similarly, modify the Update Investigator xsl.
Deploy the changes to OC Provider to the server. For more information, see Section 5.7.2.2.3.
Test the custom transformation.
To upload the AIAConfigurationProperties.xml file to MDS, perform the following steps:
Make changes to AIAConfigurationProperties.xml in $AIA_INSTANCE/AIAMetaData/config.
Add the following entry in UpdateMetaDataDP.xml in $AIA_INSTACE/config:
<fileset dir="${AIA_INSTANCE}/AIAMetaData"><include name="config/AIAConfigurationProperties.xml"/></fileset>
Navigate to <AIA_INSTANCE_HOME>/bin and run the following command as per your platform:
On Linux: source aiaenv.sh
On Windows: aiaenv.bat
Execute the following command to upload to MDS:
On Linux: ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml
On Windows: ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml
Perform the following steps to deploy OC Provider changes to server:
Create a custom deployment plan (for example, UpdateOCProviderDP.xml) as follows:
<DeploymentPlan component="StudySubjectVisitSyncSCandOC" version="3.0"><PreInstallScript></PreInstallScript><Configurations><EndpointConfigurator target-server="pips.StudySubjectVisitSyncSCandOC" dir="${AIA_HOME}"></EndpointConfigurator></Configurations><Deployments><Composite compositeName="UpdateClinicalStudyOCHealthSciencesProvABCSImpl" compositedir="${AIA_HOME}/services/core/OracleClinical/ProviderABCS/UpdateClinicalStudyOCHealthSciencesProvABCSImpl" revision="1.0" wlserver="pips.StudySubjectVisitSyncSCandOC" action="deploy" overwrite="true"/></Deployments><PostInstallScript></PostInstallScript></DeploymentPlan>
Navigate to <AIA_Instance>/bin and run the following command as per your platform to configure the installation environment:
On Linux: source aiaenv.sh
On Windows: aiaenv.bat
At the command prompt, execute the following command to deploy OC Provider:
On Linux: ant -f $AIA_HOME/Infrastructure/Install/AID/AIAInstallDriver.xml -DDeploymentPlan=$AIA_HOME/pips/StudySubjectVisitSyncSCandOC/DeploymentPlans/UpdateOCProviderDP.xml -DPropertiesFile=$AIA_INSTANCE/config/AIAInstallProperties.xml -l $AIA_HOME/pips/StudySubjectVisitSyncSCandOC/DeploymentPlans/UpdateOCProvider.log
On Windows: ant -f %AIA_HOME%\Infrastructure\Install\AID\AIAInstallDriver.xml -DDeploymentPlan=$AIA_HOME\pips\StudySubjectVisitSyncSCandOC\DeploymentPlans\UpdateOCProviderDP.xml -DPropertiesFile=%AIA_INSTANCE%\config\AIAInstallProperties.xml -l $AIA_HOME\pips\StudySubjectVisitSyncSCandOC\DeploymentPlans\UpdateOCProvider.log
Perform the steps in this section to customize EBO fields for subject activity flow.
You may have added fields to Siebel Clinical and want to send them from Oracle Clinical to Siebel. The following example shows an item that exists in the OC message, DCI book name, that does not exist in the EBO to show all the step. If the item you added exists in the EBO, but did not exist in the out-of-the-box Integration object in Siebel, you will only need to do the parts on the Siebel Provider side.
Add the fields, which you have added in Siebel that you want to send from OC, to the Clinical Subject External Integration object using Siebel tools.
Create Integration Object for this field using Siebel tools.
Create backup of files that will be modified during customization.
Add new element to Siebel Clinical xsd and upload to MDS.
Add new element to Custom EBO xsd and upload to MDS.
Map the DCIBookName to the new element in EBM in the UpdateClinicalStudyOCHealthSciencesReqABCSImpl Custom XSL file.
Map the DCIBookName to the new element in EBM in the UpdateClinicalStudySEBLHealthSciencesProvABCSImpl Custom XSL file.
Create a custom deployment plan to deploy composites on the soa server.
Test the Extension field.
Step 1: Creating Backups Before Customization
Create a backup copy of the following files on soa_server before customizing:
<AIA_HOME>/AIAMetaData/AIAComponents/ApplicationObjectLibrary/SiebelClinical/V1/schemas/ClinicalSubjectInternal.xsd
<AIA_HOME>/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/Custom/EBO/ClinicalStudy/V1/CustomClinicalStudyEBO.xsd
<AIA_HOME>/services/core/SiebelClinical/ProviderABCS/UpdateClinicalStudySEBLHealthSciencesProvABCSImpl/xsl/XformUpdateClinicalStudyReqMsgtoUpdateUpsert_InputAppReqMsg_Custom.xsl
<AIA_HOME>/services/core/OracleClinical/RequesterABCS/UpdateClinicalStudyOCHealthSciencesReqABCSImpl/xsl/Xform_ClinicalStudyABMRepMsg_to_HealthSciencesClinicalStudyEBSEBMReqMsg_Custom.xsl
Step 2: Adding New Element to Siebel xsd
In this example, to map DCIBookName element in the Siebel side located at ClinicalSubject > DCIBookName after WithdrawnReason, perform the following steps:
Note:
You must maintain the order of the element. Ensure that you add the new element in the same position you added to the Integration Object.Start Oracle JDeveloper in the local environment.
Copy the following file from soa_server file system to the local file system and open it using Oracle JDeveloper.
<AIA_HOME>/AIAMetaData/AIAComponents/ApplicationObjectLibrary/SiebelClinical/V1/schemas/ClinicalSubjectInternal.xsd
To map, expand the element ClinicalSubject, and locate the WithdrawnReason element.
Right-click WithdrawnReason and perform insert after element (WithdrawnReason > element).
Name this element with the same name as it is created in Siebel tool of type xsd:string and save the changes.
Copy the modified xsd from local file system to soa_server file system at the following location:
<AIA_HOME>/AIAComponents/ApplicationObjectLibrary/SiebelClinical/V1/schemas.
From soa_server, perform the following steps to upload the xsd file to MDS:
Update the fileset element in the UpdateMetaDataDP.xml file (at <AIA_INSTANCE_HOME>/config) to point to the location of the xsd file as shown below:
<fileset dir="${AIA_HOME}/AIAMetaData"><include name="AIAComponents/ApplicationObjectLibrary/ SiebelClinical/V1/schemas/ClinicalSubjectInternal.xsd"/></fileset>
Navigate to <AIA_HOME>/aia_instances/<instance>/bin and perform the following:
On Linux: source aiaenv.sh
On Windows: aiaenv.bat
Upload to MDS using the following command.
On Linux: ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.sql
On Windows: ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.sql
Wait until you see a build successful result.
Step 3: Adding New Element to the Enterprise Business Object
In this example, to add a field DCIBookName, perform the following steps:
Extend the component ClinicalStudyEBO in the EBO to include this field.
Start Oracle JDeveloper.
Copy the <AIA_HOME>/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/Custom/EBO/ClinicalStudy/V1/CustomClinicalStudyEBO.xsd file from soa_server file system to the local file system.
Open the following file in the local file system using Oracle JDeveloper.
<AIA_HOME>/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/Custom/EBO/ClinicalStudy/V1/CustomClinicalStudyEBO.xsd
Each type name is a place holder for the custom field it extends. For example, CustomClinicalStudySubjectType is the custom field place holders for ClinicalStudySubject business component in the ClinicalStudy EBO.
Right-click on CustomClinicalStudySubjectType and select Insert inside complexType > Sequence.
Right-click the new sequence and select Insert inside Sequence > element to add a new element to the sequence.
Name the element DCIBookName.
Set the data type for the newly added element.
Go to the source view of the xsd and find the DCIBookName element.
Enter the type of the element. In the following example, the element type is StringType. The CustomClinicalStudySubjectType tag should appear as follows in the source view:
<xsd:complexType name="CustomClinicalStudySubjectType"> <xsd:sequence minOccurs="0"> <xsd:element name="DCIBookName" type="corecom:StringType" minOccurs="0"/> </xsd:sequence></xsd:complexType>
Save the xsd file.
Copy the modified xsd from local file system to the soa_server file system at the following location:
<AIA_HOME>/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/Custom/EBO/ClinicalStudy/V1/
From the soa_server, perform the following steps to upload the xsd file to MDS:
Update <AIA_INSTANCE_HOME>/config/UpdateMetaDataDP.xml to have the following fileset entry:
<fileset dir="${AIA_HOME}/AIAMetaData"><include name="AIAComponents/EnterpriseObjectLibrary/ Industry/HealthSciences/Custom/EBO/ClinicalStudy/V1/CustomClinicalStudyEBO.xsd"/></fileset>
Navigate to <AIA_HOME>/aia_instances/<instance>/bin and perform the following:
On Linux: source aiaenv.sh
On Windows: aiaenv.bat
Upload to MDS using the following command:
On Linux: ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.sql
On Windows: ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.sql
Wait until you see a build successful result.
Step 4: Verifying if Custom EBO xsd is Uploaded to MDS
Prerequisite
Oracle JDeveloper resource palette must be configured to browse SOA_MDS database for a given database.
In Oracle JDeveloper, open the Resource Palette and navigate to the CustomClinicalStudyEBO location.
Double-click the files to open and verify the changes.
Navigate to core ClinicalStudyEBO.xsd to verify if the changes to the CustomClinicalStudyReportEBO.xsd are reflected correctly in the core EBO. Locate the CustomClinicalStudySubjectType element in the xsd.
Expand the element and navigate to the end to locate the Custom element.
Step 5: Mapping the DCIBookName to the New Element in UpdateClinicalStudyOCHealthSciencesReqABCSImpl
Prerequisite
Oracle JDeveloper must be set up with the following configurations:
Resource palette, to browse SOA_MDS database for a given database.
jws application, to which jprs can be added.
Obtain the following UpdateClinicalStudySEBLHealthSciencesProvABCSImpl and UpdateClinicalStudyOCHealthSciencesReqABCSImpl from application server to the local Oracle JDeveloper environment.
Copy composite projects from the file system of the soa server:
<AIA_HOME>/services/core/SiebelClinical/ProviderABCS and <AIA_HOME>/services/ core/OracleClinical/RequesterABCS to the local Jdeveloper environment.
In Oracle JDeveloper, click Open, and navigate to UpdateClinicalStudyOCHealthSciencesReqABCSImpl.jpr.
Expand the project and under the xsl folder, open Xform_ClinicalStudyABMRepMsg_to_HealthSciencesClinicalStudyEBSEBMReqMsg_Custom.xsl.
In the Oracle JDeveloper design view, map the existing field DCIBookName in OC ABM to the newly added field in the ClinicalStudyEBM.
Navigate to the Source tab.
Note that the template contains the mapping you created under the "<xsl:template match="/">" element.
There are multiple templates provided in the custom xsl. Cut the content enclosed in <coreclinicalstudy:Custom> tag and paste it in the appropriate template.
For this example, use ClinicalStudySubjectType_ext template.
Remove the content enclosing <xsl:template match="/"> tag that is auto generated.
Save the changes to custom xsl.
Note:
You can modify the xsl using other text editors. Ensure that the name spaces (for example, ebo, ns0) are assigned appropriately.Step 6: Mapping the DCIBookName to the New Element in UpdateClinicalStudySEBLHealthSciencesProvABCSImpl
Prerequisite
Oracle JDeveloper must be set up with the following configurations:
Resource palette, to browse SOA_MDS database for a given database.
jws application, to which jprs can be added.
In Oracle JDeveloper, click Open, and navigate to UpdateClinicalStudySEBLHealthSciencesProvABCSImpl.jpr.
Expand the project and under the xsl folder, open XformUpdateClinicalStudyReqMsgtoUpdateUpsert_InputAppReqMsg_Custom.xsl.
In the Oracle JDeveloper design view, map the custom field DCIBookName in ClinicalStudyEBM to DCIBookName in Siebel ABM.
Navigate to the Source view of the custom xsl.
Note that there are multiple templates provided in the custom xsl. Design view adds the mapping created in step 2 to a default template <xsl:template match="/">.
Cut and paste the content to the correct template to modify the default template. For example, < DCIBookName > should be moved to the ClinicalSubjectType_ext template.
For example,
<xsl:template name="ClinicalSubjectType_ext"><xsdLocal1:DCIBookName><xsl:value-of select="/ns0:UpdateClinicalStudyEBM/ns0:DataArea/ ns0:UpdateClinicalStudy/ns0:ClinicalStudySubject/ns0:Custom/coreclinicalstudycust:DCIBookName"/></xsdLocal1:DCIBookName></xsl:template>
Remove the content surrounding <xsl:template match="/"> that is auto generated.
Save the changes to the custom xsl.
Step 7: Deploying the Composites
On the application server, ensure that UpdateClinicalStudyOCHealthSciencesReqABCSImpl and UpdateClinicalStudySEBLHealthSciencesProvABCSImpl are updated with customizations.
This involves copying the modified custom xsls to the application folders of the server $AIA_HOME/services/core/SiebelClinical/ProviderABCS/ UpdateClinicalStudySEBLHealthSciencesProvABCSImpl/xsl and $AIA_HOME/services/core/OracleClinical/RequesterABCS/ UpdateClinicalStudyOCHealthSciencesReqABCSImpl/xsl.
Open the $AIA_HOME/ pips/StudySubjectVisitSyncSCandOC/DeploymentPlans/StudySubjectVisitSyncSCandOCCustomDP.xml file.
Replace <Deployments> </Deployments> with the following:
<Deployments><CompositecompositeName="UpdateClinicalStudyOCHealthSciencesReqABCSImpl"compositedir="${AIA_HOME}/services/core/OracleClinical/ RequesterABCS/UpdateClinicalStudyOCHealthSciencesReqABCSImpl" revision="1.0" wlserver="pips.StudySubjectVisitSyncSCandOC" action="deploy" overwrite="true"/><Composite compositeName="UpdateClinicalStudySEBLHealthSciencesProvABCSImpl" compositedir="${AIA_HOME}/services/core/SiebelClinical/ProviderABCS/UpdateClinicalStudySEBLHealthSciencesProvABCSImpl" revision="1.0" wlserver="pips.StudySubjectVisitSyncSCandOC" action="deploy" overwrite="true"/></Deployments>
Save the file.
Navigate to <AIA_HOME>/aia_instances/<instance>/bin/ and run the following command as per your platform to configure the installation environment:
On Linux: source aiaenv.sh
On Windows: aiaenv.bat
Run the following custom deployment command for deploying customized artifacts:
On Linux: ant -f $AIA_HOME/Infrastructure/Install/AID/AIAInstallDriver.xml -DDeploymentPlan=$AIA_HOME/pips/StudySubjectVisitSyncSCandOC/DeploymentPlans/StudySubjectVisitSyncSCandOCCustomDP.xml -DPropertiesFile=$AIA_INSTANCE/config/AIAInstallProperties.xml -l <location and name where you want the log file written>
On Windows: ant -f %AIA_HOME%\Infrastructure\Install\AID\AIAInstallDriver.xml -DDeploymentPlan=$AIA_HOME\pips\StudySubjectVisitSyncSCandOC\DeploymentPlans\StudySubjectVisitSyncSCandOCCustomDP.xml -DPropertiesFile=%AIA_INSTANCE%\config\AIAInstallProperties.xml -l <location and name where you want the log file written>
Step 8: Testing the Custom Extension
You must test the custom field you have added.
Table 5-5 describes the configuration properties available for the Study, Subject and Visit Synch: Siebel Clinical –Oracle Clinical PIP:
Table 5-5 Configuration Properties
| Service Name | Property Name | Value | Description |
|---|---|---|---|
|
UpdateClinicalStudySEBLHealthSciencesReqABCSImpl |
Default.SystemID |
SEBLCLIN_01 |
Default System ID is associated with this service. It is used for searching the DVMs and XREFS when no other system IDs are found in the system registry. |
|
ABCSExtension.PreXformABMtoEBMClinicalStudyABM |
false (default), true |
Custom extension before the execution of transformation of Application Business Message (ABM) to Enterprise Business Message (EBM). |
|
|
ABCSExtension.PreInvokeEBSHealthSciencesClinicalStudyEBSV1EBM |
false (default), true |
Custom extension just after execution of transformation of ABM to EBM and before the call to the Enterprise Business Service (EBS). |
|
|
Routing.HealthSciencesClinicalStudyEBS.UpdateClinicalStudy.RouteToCAVS |
false (default), true |
To test the requester Application Business Connector Service (ABCS) or when the provider ABCS is not available, you would want the requester ABCS to call a Simulator instead of Actual Oracle AIA services. |
|
|
Routing.HealthSciencesClinicalStudyEBS.UpdateClinicalStudy.CAVS.EndpointURI |
http://<<soaservername>>:<<port>>/AIAValidationSystemServlet/asyncresponseSimulator |
End point URL for CAVS, when RouteToCAVS property is set to true. |
|
|
UpdateClinicalStudySEBLHealthSciencesProvABCSImpl |
Default.SystemID |
SEBLCLIN_01 |
Default System ID is associated with this Service. It is used for searching the DVMs and XREFS when no other system IDs are found in the system registry. |
|
ABCSExtension.PreXformEBMtoABMClinicalStudyEBM |
false (default), true |
Customer extension just before the execution of the EBM to ABM transformation. |
|
|
Routing.Upsert.RouteToCAVS |
false (default), true |
To test the provider ABCS or when the provider application is not available, you would want the provider ABCS to call a simulator instead of an actual provider application service. |
|
|
Routing.Upsert.CAVS.EndpointURI |
http://<<soaservername>>:<<port>>/AIAValidationSystemServlet/syncresponseSimulator |
End point URL for CAVS, when RouteToCAVSproperty is set to true. |
|
|
Routing.Upsert.SEBLCLIN_01.EndpointURI |
${participatingapplications.sc.server.InternetProtocol}${participatingapplications.sc.server.host}:${participatingapplications.sc.server.port}/eai_${participatingapplications.sc.server.Language}/start.swe?SWEExtSource=SecureWebService&SWEExtCmd=Execute&WSSOAP=1 |
End point URL for Siebel Clinical participating application. |
|
|
Routing.Upsert.MessageProcessingInstruction.EnvironmentCode |
PRODUCTION (default), CAVS |
Setting the value to PRODUCTION indicates that the request must be sent to a concrete Endpoint. Setting the value to CAVS indicates that the request must be sent to CAVS Simulator. |
|
|
ABCSExtension.PreInvokeABSUpsert_InputABM |
false (default), true |
Customer extension just before the invocation of Upsert call to Siebel. |
|
|
ABCSExtension.PostInvokeABSUpsert_InputABM |
false (default), true |
Customer extension just after invoking Upsert call to Siebel. |
|
|
UpdateClinicalStudyOCHealthSciencesReqABCSImpl |
Default.SystemID |
OC_01 |
Default System ID is associated with this service. It is used for searching the DVMs and XREFs when no other system IDs are found in the system registry. |
|
ABCSExtension.PreXformABMtoEBMClinicalStudyABM |
false (default), true |
Custom extension before the execution of transformation of ABM to EBM. |
|
|
Routing.ClinicalStudyEBSV1.RouteToCAVS |
false (default), true |
To test the requester Application Business Connector Service (ABCS) or when the provider ABCS is not available, you would want the requester ABCS to call a simulator instead of actual Oracle AIA services. |
|
|
Routing.ClinicalStudyEBSV1.CAVS.EndpointURI |
http://<<soaservername>>:<<port>>/AIAValidationSystemServlet/syncresponseSimulator |
End point URL for CAVS, when RouteToCAVS Property is set to true. |
|
|
ABCSExtension.PreInvokeEBSHealthSciencesClinicalStudyEBSEBM |
false (default), true |
Custom extension before the invocation of the EBS. |
|
|
UpdateClinicalStudyOCHealthSciencesProvABCSImpl |
Default.SystemID |
OC_01 |
Default System ID is associated with this service. It is used for searching the DVMs and XREFs when no other system IDs are found in the system registry. |
|
ABCSExtension.PreXformEBMtoABMClinicalStudyEBM |
false (default), true |
Customer extension just before the execution of the EBM to ABM transformation. |
|
|
Routing.StudySiteServiceSoapHttpPort.RouteToCAVS |
false (default), true |
To test the requester Application Business Connector Service (ABCS) or when the provider ABCS is not available, you would want the requester ABCS to call a Simulator instead of Actual Oracle AIA services. |
|
|
Routing.StudySiteServiceSoapHttpPort.CAVS.EndpointURI |
http://<<soaservername>>:<<port>>/AIAValidationSystemServlet/syncresponseSimulator |
End point URL to invoke the Oracle Clinical Study Site web service. |
|
|
Routing.SiteServiceSoapHttpPort.OC_01.EndpointURI |
http://${participatingapplications.ocrdc.server.http.host}:${participatingapplications.ocrdc.server.http.port}/OracleClinical-context-root/SiteServiceSoapHttpPort |
End point URL to invoke the Oracle Clinical Site web service. |
|
|
Routing.SiteServiceSoapHttpPort.MessageProcessingInstruction.EnvironmentCode |
PRODUCTION (default), CAVS |
Setting the value to PRODUCTION indicates that the request must be sent to a concrete Endpoint. Setting the value to CAVS indicates that the request must be sent to CAVS simulator. |
|
|
Routing.InvestigatorServiceSoapHttpPort.RouteToCAVS |
false (default), true |
To test the provider ABCS or when the provider application is not available, you would want the provider ABCS to call a simulator instead of an actual provider application service. |
|
|
Routing.InvestigatorServiceSoapHttpPort.CAVS.EndpointURI |
http://<<soaservername>>:<<port>>/AIAValidationSystemServlet/syncresponseSimulator |
End point URL for CAVS, when RouteToCAVS property is set to true. |
|
|
Routing.InvestigatorServiceSoapHttpPort.OC_01.EndpointURI |
http://${participatingapplications.ocrdc.server.http.host}:${participatingapplications.ocrdc.server.http.port}/OracleClinical-context-root/InvestigatorServiceSoapHttpPort |
End point URL to invoke the Oracle Clinical Investigator web service. |
|
|
Routing.InvestigatorServiceSoapHttpPort.MessageProcessingInstruction.EnvironmentCode |
PRODUCTION (default), CAVS |
Setting the value to PRODUCTION indicates that the request must be sent to a concrete endpoint. Setting the value to CAVS indicates that the request must be sent to CAVS simulator. |
|
|
ABCSExtension.PreInvokeABSStudySiteABM |
false (default), true |
Customer extension just before the invocation of the Study Site Service in Oracle Clinical. |
|
|
ABCSExtension.PostInvokeABSStudySiteABM |
false (default), true |
Customer extension just after invoking the Study Site Service in Oracle Clinical. |
|
|
CustomXForm.InvestigatorABM |
false (default), true |
If set to true, it invokes the custom transformation file for Investigator ABM (Custom_xForm_CreateInvestigatorABM.xsl). |
|
|
CustomXForm.SiteABM |
false (default), true |
If set to true, it invokes the custom transformation file for Site ABM (Custom_xFrom_CreateSiteABM.xsl). |
|
|
CustomXForm.StudySiteABM |
false (default), true |
If set to true, it invokes the custom transformation file for Study Site ABM (Custom_xForm_CreateStudySiteABM.xsl). |
|
|
AIASessionPoolManager |
all_hosts |
SEBLCLIN_01 NOSERVER |
SPM can work with multiple application web server instances. In this property, list the hosts for which SPM can create a session token pool. Separate the host names by spaces. Each host has its own pool. This property is not prefixed with a Host ID value. |
|
all_hosts.ProxySettings_Enabled |
False |
To enable SPM use proxy settings while calling the application web server, set this property to true. Set this property to FALSE to not use proxy settings. |
|
|
all_hosts.Proxy.Host |
Specified by values populated in the Configuration Wizard. |
It determines the server to be set in the system properties for http.proxyHost property. In the java.net API used by SPM, proxies are supported through two system properties: http.proxyHost and http.proxyPort. They must be set to the proxy server and port respectively. This value is only set when ProxySettings_Enabled is set to true. |
|
|
all_hosts.Proxy.Port |
Specified by values populated in the Configuration Wizard. |
It determines the port to be set in the system properties for the http.proxyPort property. In the java.net API used by SPM, proxies are supported through two system properties: http.proxyHost and http.proxyPort. They must be set to the proxy server and port respectively. This value is only set when ProxySettings_Enabled is set to true. |
|
|
SEBLCLIN_01.EndpointURI |
Populated by values specified in the ConfigurationWizard. (For example, <InternetProtocol>://<hostname>:<port>/eai_<language>/start.swe?SWEEXTSource=SecureWebService&SWEExtCmd=Execute&WSSOAP=1 |
It determines the endpoint URI that Session Pool Manager uses to connect to the application web server. |
|
|
SEBLCLIN_01.UserId |
Populated by values specified in the PIP Configuration Wizard. |
It determines the user ID that is used to connect to the application web server. |
|
|
SEBLCLIN_01.Password |
Populated by values specified in the PIP Configuration Wizard. |
It determines the password that is used to connect to the application web server. This value is stored in the KEY store and is encrypted. |
|
|
SEBLCLIN_01.PredictExpiration_Idle |
780000 |
Indicates the maximum time in milliseconds that a session token can be idle before expiring. Oracle recommends you to set this value to a value lower than the actual maximum idle time configured for the application web server. This value is recommended to compensate for the gap between the time at which the application web server responded and the time at which the BPEL flow called SPM to release the session token. |
|
|
SEBLCLIN_01.PredictExpiration_Age |
82800000 |
Indicates the maximum age in milliseconds that a session token can reach before expiring. Oracle recommends you to set this value to a value lower than the actual maximum age configured for the application web server. The creation time registered in the application web server is some seconds earlier than the one registered in SPM. A value of 1or 2 minutes is a good start. For example, if the maximum age configured on the application web server is 15 minutes, set this property to 13 minutes. |
|
|
SEBLCLIN_01.InvalidSessionErrorCodes |
10944642|SBL-BPR-00162|SBL-DAT-00175|11338608|SBL-UIF-00880 |
It determines the list of error codes that the application Web server can return for a fault when the session token is not valid. |
|
|
SEBLCLIN_01.ClassName |
oracle.apps.aia.core.sessionpool.CRMSiebelSession |
It determines the full class name that SPM uses to get the session tokens from the application server. The class listed in this property implements the oracle.apps.aia.core.sessionpool.PoolableResource interface. |
At times, applications are moved to new servers or databases for various reasons. This section describes how to update the information that was provided during install time when the integration is already installed and deployed.
Also, while running the configuration wizard, if you have entered a wrong port number or want to move the Siebel application to another machine, you can modify the file and upload these changes to MDS.
To modify information about Siebel Clinical, perform the following steps:
The information about the Siebel Clinical host name and port given during install is used to define the EndPointURI to call the Siebel Web services. If you have moved Siebel Clinical to a new server, you must update the SEBCLIN_01.EndPointURI property in the AIAConfigurationProperties.xml file.
Navigate to $AIA_INSTANCE/AIAMetaData/config directory.
Open the file AIAConfigurationProperties.xml.
Search for SEBLCLIN_01.EndpointURI.
Replace the host name and port, if they have changed.
Upload the updated AIAConfigurationProperties.xml file to MDS. Perform the following steps to upload the file to MDS:
Update the fileset element in the $AIA_INSTANCE/config/UpdateMetaDataDP.xml file to point to the location of the AIAConfigurationProperties.xml file as shown below:
<fileset dir=$AIA_INSTANCE/AIAMetaData/"><include name=" config/AIAConfigurationProperties.xml" /></fileset>
Navigate to <AIA_HOME>/aia_instances/<instance>/bin and perform the following:
On Linux: source aiaenv.sh
On Windows: aiaenv.bat
Upload to MDS using the following command.
On Linux: ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.sql
On Windows: ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.sql
Wait until you see a build successful result.
You can change the passwords specified at the time of AIA installation post-install. To change passwords, AIA provides a utility called UpdateStore. AIA stores the passwords in keystore. This utility modifies the existing passwords in the keystore.
To run this utility, the AIAIntallProperties.xml properties file should exist in the corresponding AIAHOME/AIA_INSTANCE/<Instance name>/config folder and the password being modified must exist in the file.
Note:
This utility only updates encrypted passwords in AIA installation. It will not change passwords of the SOA server or the database schemas.Navigate to <AIA_Instance>/bin and run the following command as per your platform to configure the installation environment:
On Linux: source aiaenv.sh
On Windows: aiaenv.bat
Navigate to AIA_HOME/util/.
Execute the following command:
ant -f updateStore.xml updateStore -DAdminUsername=<weblogic adminusername> -DAdminPassword=<weblogic admin password>
The Update AIA keystore screen is displayed.
Enter the existing user name, existing password, new user name, and new password and the Xpath of the password which you want to change.
Note:
This utility modifies the user name and the password in the AIAInstallProperties.xml. This does not synchronize the AIAInstallProperties.xml in the MDS. You need to do it manually.If you want to change the password under the o2c tag, enter the following values in the screen that appears.
Existing user name:
Existing password:
New user name:
New password:
XPath: /properties/participatingapplications/sc/server/eai/password
For more information, see Oracle® Fusion Middleware Installation and Upgrade Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.4.0) Guide.
If the password, host name, or port of OC changes, it impacts OracleClinicalCoreDS and UpdateClinicalStudyOCDS data source. In such a scenario, perform the following steps:
Log in to the Weblogic console.
On left-hand side navigation hierarchy, navigate to soa_domain > Services > Data Sources
Click OracleClinicalCoreDS.
Click the Connection Pool tab.
Change the password, host name, and port and click Save.
Change the password, host name, and port for UpdateClinicalStudyOCDS following the steps from 3 to 5.
Based on the roles defined for the services, email notifications are sent if a service errors out.
For more information about Oracle Clinical errors, see the Oracle Clinical documentation.
For more information about AIA error handling, see the Oracle Application Integration Architecture - Foundation Pack: Core Infrastructure Components Guide, "Setting Up and Using Error Handling and Logging."
| Problem | Solution |
|---|---|
|
Instances are not getting generated in the AIA layer when Siebel user selects the Activate for Synchronization check box. |
Perform one of the following:
|
|
UpdateClinicalStudySEBLHealthSciencesReqABCSImplProcess is in faulted state with the following error: The value entered for the State '<to be replace>' does not exist in '<SEBLCLIN_01>,' column for the STATE DVM. Please add the value to the STATE DVM. |
Ensure that STATE.dvm has appropriate state codes listed in the SEBLCLIN_01 column. You can add or modify the DVM values using the following:
|
|
UpdateClinicalStudyOCHealthSciencesProvABCSImplProcess is in faulted state with the following error: The value entered for the State '<to be replace>' does not exist in the <OC_01> column for the STATE DVM. Please add the value to the STATE DVM. |
Ensure that STATE.dvm has appropriate state codes listed in the OC_01 column. You can add or modify the DVM values using the following:
|
|
Email notifications are not coming. |
Perform one of the following:
|
|
Updates to AIAConfigurationProperties.xml are not reflected in the actual business flow. |
Perform one of the following:
|
|
Instance is created in the OC AQ clin_study_queue_tbl table but not picked by UpdateClinicalStudyOCAQConsumer. |
Check if dequeue is enabled on OC AQ. If not, you can enable it by executing the following command on the RXC schema of OC DB:
|
|
Failed to invoke end component oracle.pharma.oc.model.services.server.webservice.SiteServer (POJO), operation=createSite.
|
Check that the state in the Site address is defined as a region of type state within a region of type country for the country passed in the site address. |
|
The requested visit could not be located in the database. |
Check that the activity name defined in OC matches exactly with the clinical item defined in SC. |
|
Error running subprocess 'SWI LS Clinical Subject Inbound - Activity' at step 'Send to Activity Flow'.(SBL-BPR-00183) |
This error occurs when a blank completion date is sent for an activity which was already marked as completed in SC. An investigator or site may have been paid for an activity or visit that did not occur. You must manually adjust this in SC. |
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|