SBL-SVC-00232

Applies to:

Siebel Life Sciences CRM - Version 8.1.1.8 SIA [23012] and later
Information in this document applies to any platform.

Symptoms

When using Application Deployment Manager (ADM) to migrate non-repository objects, the following error occurs:

The schema of the source environment and the target environment must be of the same version.(SBL-SVC-00232)

STEPS TO REPRODUCE


Environment:

Source Environment, schema version = 45.19.0.0
Target  Environment, schema version = 48.32.0.0.

1. Create ADM Project for LOVs.
2. Deploy ADM Project.


3. The LOV data is exported to an XML file.

XML file contains:
<SchemaVersion>45.19.0.0</SchemaVersion>

4. Import the generated XML file into the Target environment.



Error Message Displays:

    The schema of the source environment and the target environment must be of  the same version.(SBL-SVC-00232).

Cause

ADM checks the Schema version of the Source Environment with the
Schema version of the Target when deploying data to ensure they match.


The following bug addresses this issue in 8.1.1.8:


Bug 15862953 DISABLE SCHEMA VERSION CHECKING WHEN DEPLOYING DATA USING ADM


This issue is fixed in the 8.1.1.10 Fix Pack.

Solution

STEPS


Install QF0000041 for 8.1.1.8 (Patch 16405541)

Summary: ADM FAILS WHEN SOURCE AND TARGET SCHEMAS ARE NOT SAME VERSION



1. Click 'Patches & Updates' screen tab [see upper right hand corner of this My Oracle Support]
2. Go to Patch Name or Number from the Search tab
3. Enter the Patch Number : 16405541
4. Press Search
5. Click on the patch that contains your platform
6. Click the Read Me button to see the information contained in the Quick Fix Release Notes
7. Click the Download button
8. Download all parts. The first contains the Readme file with installation instructions.
9. Be sure to read and follow directions in the Readme file.
 

   Note: There are configuration changes in addition to the Quick Fix:

  Log into Siebel Tools.
     a. In the Object Explorer, click on the Business Service object.
     b. Query for the UDA Service.
     c. Create a new business service user property with the following values:
         Name: IgnoreSchemaCheck
         Value: Y
     d. Compile the SRF.

10. Apply this patch to all Siebel components.
11. Install and test in a Development environment BEFORE installing into a Production environment.

Applies to:

Siebel System Software - Version 7.7.1 SIA [18306] to 8.2.2 SIA[22320] [Release V7 to V8]
Information in this document applies to any platform.

Area(s):ADM - App. Deployment Manager, Siebel EAI

Release(s):V7 (Enterprise), V7 (Professional)

Database(s):All Supported Databases

App Server OS(s):All Supported Platforms

Latest release tested against:V7 (Enterprise)

Keywords:Application Deployment Manager, ADM, UDA, EMT



This document was previously published as Siebel Troubleshooting Steps 41.

Purpose

How To Troubleshoot Application Deployment Manager (ADM)

Troubleshooting Steps

 

The
information presented in this document is intended to help troubleshoot
ADM related problems and the most commonly reported symptoms and error
messages while running Application Deployment Manager (ADM).

 

ADM
is a new feature in Siebel version 7.7 that helps Siebel administrators
easily and quickly automate the migration of key reference data across
different Siebel environments, such as between a development and a test
environment. This troubleshooting document is a supplement to Siebel
Bookshelf version 7.7 > Going Live with Siebel eBusiness Applications
> Migrating Customizations Between Applications.

 

 

Note:
This document may not be fully applicable for Siebel version 8.x due to
the new ADM architecture, for more information please review Siebel
Application Deployment Manager Guide from version 8.x.

 

 

Contents

Troubleshooting Overview

Table 1 - Deployment Session Status Field Values

Table 2 - Component Events to Enable for ADM Troubleshooting

Figure 1 - Location of Log Files for ADM errors

Table 3 - ADM Session Log.

Architecture

Figure 2 - Siebel Components and Objects Used in ADM

ADM Workflow Processes for Online Deployments

Figure 3 - Workflow Process and Business Services Used for Online Deployment

ADM Business Services for File Deployments

Figure 4 - Business Services Used for File Deployment

Common ADM Error Messages

Table 4 - Common ADM Error Messages and Symptoms

Figure 5 - Hierarchical LOV Deployment with LOVs of the Same LOV Type

Figure 6 - Hierarchical LOV Deployment with LOVs of Different LOV Type

 

 

Troubleshooting Overview

 

Because
ADM is designed with standard Siebel Business application components
and objects, many tools already exist for troubleshooting the individual
Siebel components. The challenge is to understand how the components
communicate with each other and the sequence of events. An understanding
of the ADM architecture and workflow processes is critical to
successful isolating and resolving problems.

 

The general steps for troubleshooting are:

 

1. Navigate
   to Site Map > Application Deployment Manager > Deployment Session
   View View and locate your ADM session’s status. The status will let you
   know if there is an error. See Table 1 for an explanation of the
   session statuses and first steps.

 

2. Check
   the source and target systems for log files or error messages. The
   locations where logs can be found are shown in Figure 1. Log file
   locations for the Siebel server and a dedicated client are shown. If you
   are performing an online deployment OR a file deployment connected to a
   thin client, the logs you want to examine will be on the Siebel server.
   If you are performing a file deployment on the dedicated client, the
   logs you want to examine will be on the dedicated client.

 

3. Once
   you have found the relevant log files, scan the component logs to find
   the first point of failure. Typical error messages for ADM are listed in
   this Troubleshooting guide.

 

4. If
   the logs do not contain any detail, enable the appropriate component
   events for each server component. See Table 2 for a list of the
   component events to enable and which components to enable them on.

 

5. If
   you identify the problem to be related to an integration object,
   business component rules or the EAI Siebel Adapter, then do further
   testing using export files.

 

Once you have resolved the problem, re-create your ADM session and deploy it again.

 

Table 1 - Deployment Session Status Field Values

 

Status	Description	Diagnostic
New	This is a new deployment session.	Deployment session has not submitted yet.
Submitted	This is a status that you will usually see for HTTP deployments. This means data has been sent successfully sent from the source system to the target system.	On the Source system, you will see the Submitted status until the jobs complete on the Target system.   If the status never changes on the source system, check target system for queued or failed server requests (jobs). Typically these requests will be in the WorkFlow Process Manager server component. To find the jobs, navigate to Site Map > Administration - Server Management > Jobs.   On the target system, also make sure the Workflow component group is online, and you have synchronized the batch components.
Validation Failed	This status indicates that the source system was unable to validate the environment details (see error SBL-SVC-00232) or log into the target server.	Check the source system log file in the $SIEBSRVR/temp/<session_id>.log for the underlying error message.
Deployment Failed	The deployment failed.	Check the source system log file in the $SIEBSRVR/temp/<session_id>.log for the underlying error message.   If it was an online deployment, also check target system for Workflow or EAI object manager logs for any errors.
Incomplete Deployment	Some items did not deploy successfully. Other items may have been deployed successfully.	Check the source system log file in the $SIEBSRVR/temp/<session_id>.log for the underlying error message.   If it was an online deployment, also check target system for Workflow or EAI object manager logs for any errors.
Export Completed	This is a status usually for file deployments. It indicates a successful file export.	The ADM data was exported successfully from the source system. Check the specified file directory for the output file.   NOTE: this status does not indicate that data was imported into the target system.
Deployment Completed	This status indicates successful data migration from source to target.	The submitted deployment ran successfully on the target system, and an acknowledgement was successfully sent back and received.

 

 

Table 2 - Component Events to Enable for ADM Troubleshooting

 

Component Event Name (Alias)	Level	Description	Components*
ADM Event (ADM Event)	4	Captures events related to ADM, such as errors.	EAIObjMgr, WfProcMgr, the AOM
EAI Siebel Adapter (EAISiebAdpt)	4	Captures EAI Siebel Adapter related events, including integration component and integration component fields accessed, and the values for the fields; business components and business component fields accessed and the values for the fields.	WfProcMgr, the AOM
EAI Transport (EAITransport)	4	Captures EAI Transport related events: including direction (send/receive) and result. For HTTP transport, shows headers and responses. For File Transport, shows the full filename.	EAIObjMgr, WfProcMgr, the AOM
Performance Event (FSMPerformance)	4	Captures events related to the File Systems performance such as time taken to read or write to the file system, and the name of file.	EAIObjMgr, WfProcMgr, the AOM
Event Context (EventContext)	4	Captures applet and method executed, view names, and screen names that the user navigates to.	the AOM
SrmBusSvc Condition (SRMBusSvc)	3	Captures when the Server Requests business service submits a job.	EAIObjMgr, WfProcMgr, the AOM, SRProc, SRBroker
Server Requests Routing Info (SRMRouting)	4	Captures Server Requests routing information, including SRB Session ID and component name.	EAIObjMgr, WfProcMgr, the AOM, SRProc, SRBroker
Object Manager SQL Log (ObjMgrSQLLog)	4	Captures the SQL select, insert, update, and delete statements.	EAIObjMgr, WfProcMgr, the AOM
Session Manager (SessMgr)	3	Captures SISNAPI events related to the Siebel session manager.	WfProcMgr, the AOM
Object Manager Business Service Operation and SetErrorMsg Log (ObjMgrBusServiceLog)	4	Captures Business Service-related events such as when business services are created, deleted, and the methods invoked.	EAIObjMgr, WfProcMgr, the AOM
Object Manager Business Component Operation and SetErrorMsg Log (ObjMgrBusCompLog)	4	Captures Business Component-related events: create and delete.	EAIObjMgr, WfProcMgr, the AOM
Workflow Engine Invoked (EngInv)	4	Captures when the workflow process engine is invoked.	EAIObjMgr, WfProcMgr
Workflow Process Execution (PrcExec)	4	Captures workflow process related events, and shows process properties values.	EAIObjMgr, WfProcMgr
Workflow Step Execution (StpExec)	4	Captures the process step events including business services invoked and inputs and outputs of the business services, conditions evaluated, and outcome of the step.	EAIObjMgr, WfProcMgr
XML Conversion (XMLConversion)	4	Captures the conversion of XML documents to property sets steps and vice versa, shows encoding used in the document.	EAIObjMgr, WfProcMgr

 

*
AOM refers to your application object manager. If you are connected
through the Siebel Web Client, you are using an application object
manager, such as CallCenter (SSCObjMgr_enu).

 

You
can enable more events than those listed in Table 2. The events listed
in Table 2 are intended as a starting point for troubleshooting generic
ADM problems. For more information about the component event
infrastructure, refer to Siebel Bookshelf version 7.7 > System
Monitoring and Diagnostics Guide for Siebel eBusiness Applications >
Configuring Siebel Server and Component Logging > Configuring Siebel Server Component Logging.

 

Figure 1 - Location of Log Files for ADM errors

 

 

 

On
the source system, the ADM log file in the $SIEB_ROOT/temp directory
often contains more information than you will see on the screen. The ADM
Session will show a hyperlink to the log file. Even if you do not see a
file listed in the ADM Session, check the Siebel server temp directory
for a file.

A
sample log where a deployment failed and the reason it failed is shown
below in Table 3. The filename will be the name of the deployment
session with a .log suffix.

 

Table 3 - ADM Session Log. Filename Is 42-4P84F.log

 

Line #	Text
1	[Deployment Session Header]
2	ADM Deployment Session: 42-4P84F
3	ADM Deployment Project: testtest
4	Start Time: 08/01/2004 17:00:00
5	Target Web Address: http://myserver/eai_enu
6	Target User Name: SADMIN
7
8	[Transaction: ProdFeature]
9	Status: Data Preparation Completed
10	Session Items: UDA Admin Product Line, UDA Product Feature
11	End Time: 08/01/2004 17:00:07
12
13	[Transaction: ProdFeature]
14	Status: Import Failed
15	End Time: 08/01/2004 17:00:17
16	EAI Logs:
17	No inserts are allowed in Integration Component 'Admin Product Line_Internal Product'. (SBL-EAI-04184)

 

In
the sample ADM Session log, you can see the name of the ADM project
testtest in line 3, as well as the target server name myserver in line
5. You can also quickly see that the deployment data type, ProdFeature
in line 8 and line 13, and the final status Import Failed in line 14. 
The Status Data Preparation Completed on line 9 means that the source
system was able to successfully query and get information from the
Source system. But then the import into the Target system failed as
shown by the status in Line 14. The failure error message is in line 17.

 

At this
point, you should check the Target system for WfProcMgr logs (workflow
process manager tasks) where the EAI Siebel Adapter is used to update or
insert the data. In this case, the reason is because the standard Admin
Product Line Internal Production integration component does not allow
inserts. In order to successfully deploy the Product Feature data, the
products associated with the Product Lines must already exist on the
target system.

 

Architecture

 

ADM is built on the Server Requests, Workflow Process and Enterprise Application Integration (EAI) infrastructure.

 

Figure
2 presents a logical overview of the different components involved.
There are two environments shown, a source and target. Each environment
is a distinct Siebel enterprise with its own Siebel database and
server(s). The Siebel database for each environment contains tables that
store data that is to be migrated (i.e. LOV data), ADM workflow process
definitions, job details for the server requests, and entries in the
EAI Queue. Each Siebel enterprise has an SRF which contains the ADM
integration objects. Each enterprise will also have access to its own
Siebel FileSystem, which will temporarily store files used in the ADM
session.

 

On
the source system, you need to have the Workflow and System Management
component groups online. On the target system, you need to have the EAI,
Workflow and System component groups online; you also need to setup the
Siebel Web Server so that the target system can receive the HTTP
requests. (If you are deploying using Export file, you would not use the
Siebel server components or the Web Server, but all the other
components below the dashed line are still required.)

 

Figure 2 - Siebel Components and Objects Used in ADM

 

 

 

 

 

ADM Workflow Processes for Online Deployments

 

The
workflow processes used by ADM and standard integration objects’ names
start with the letters UDA (for Universal Deployment Agent). The primary
business service used in the UDA workflow process is the UDA Service.
The sequence of events, workflow processes and business services for an
online ADM session are outlined in Figure 3. Because of differences in
the flow and architecture for a deployment using export files, that
process is outlined separately in Figure 4.

 

Figure 3 - Workflow Process and Business Services Used for Online Deployment

 

 

 

Figure
3 also illustrates the flow of data in an online deployment. When you
click Deploy in the ADM views, the button invokes the UDA Deployment
workflow process. The UDA Deployment workflow process runs in the
current application object manager you are using. So for example, if you
are logged into the Financial Services object manager, it will run in
the FinsObjMgr_enu component. The UDA Deployment workflow process then
runs a subworkflow process, UDA Environment Verification, to verify that
the Target environment is up and its schema versions match those in the
Source environment. The UDA Environment Verification workflow processes
use HTTP at this point to communicate with the Target system.

 

On
the target system, the EAI Object Manager receives the request from the
UDA Environment Verification workflow process through the UDA Deploy
named subsystem. The UDA Deploy named subsystem dispatches the request
to the UDA Service business service and the UDA Service sends a response
back to the source system.

 

After
verification is complete, on the source system, the UDA Deployment
workflow process uses the Server Requests business service to submit an
asynchronous workflow process job. The workflow process task invokes the
UDA Data Query workflow process. The UDA Data Query workflow process
uses the EAI Siebel Adapter and method query to extract data that to be
deployed (into a Siebel integration object and then into XML). Once the
ADM data is obtained, it is sent from the source to the target system
using the UDA HTTP Transport workflow process as a sub workflow process.

 

On
the target system, the EAI Object Manager receives the ADM data from
the UDA HTTP Transport workflow process through the UDA Deploy named
subsystem. This time UDA Deploy named subsystem uses the Server Requests
business service to submit an asynchronous workflow process job. A new
workflow process manager task runs the UDA Target Workflow workflow
process. In the UDA Target Workflow, the EAI Siebel Adapter, with method
Upsert (in Siebel version 7.7), is used for the logic of determining if
the data will be updated or inserted. Upon successful processing of the
ADM Data, the workflow process manager sends a confirmation back to the
source using the SISNAPI protocol.

 

On
the source system, the confirmation request is received by the same
application object manager that originally initiated the deployment. The
UDA Acknowledgement workflow process runs to update the ADM Session
data with the results from the target system.

 

ADM Business Services for File Deployments

 

Figure
4 illustrates the flow of data in a deployment using export files.
Unlike batch or online deployments, when you use export files, you do
not need to have a running Siebel server. There are also no explicit
workflow processes invoked. The architectural simplification makes the
file deployment option ideal for testing ADM.

 

If
you encounter an error performing an online deployment, switching your
test case to a file deployment is a good way to isolate the root cause
of the error. When you test with the file deployment option on a
dedicated client, you can enable client-side tracing so you can see more
details on what may be happening with the underlying Siebel application
layers. You can focus on errors specific to the integration objects,
content objects or EAI Siebel Adapter, and not be concerned with Siebel
server infrastructure. For steps on how to perform client logging, refer
to How Should Client Side Logging Be Set? (Doc ID 475587.1).

 

 

Figure 4 - Business Services Used for File Deployment

 

 

 

In
Figure 4, the application object manager represents the object manager
engine in a dedicated client or in a zero foot print client. In a file
deployment, you need to create an XML file that represents the ADM data
first in the source system. The file needs to be saved in a location
that is accessible by both the source and the target environments.

 

On
the target system, you import the file created from the source system.
When the XML file is deployed on the target system, a copy of the XML
file is saved in the EAI Queue. When the update or insert is complete on
the target system, a broadcast message is displayed on the target
system to the position of the user who initiated the import

 

On
the source system, you will still need to create an ADM project and a
new ADM Session. However, when you click the Deploy button in a File
deployment scenario, no workflow processes will be dispatched. Instead,
the UDA Service will provide the logic to create an XML file containing
the ADM deployment data.  On the target system, you can directly import
the XML file using the Menu -> Deploy from File option. You do not
need to have the EAIObjmgr running or any deployment session or project
created on the target system.

 

The
drawback to using file deployment is that you will not have a record
showing if an import succeeded or failed on the source or target system.
Since there is no HTTP or SISNAPI established between the target and
source environment in a file deployment, there is no ADM view that shows
if the deployment data was successfully imported. If there is a failure
on the target system to import the data, you will see the message in
the client GUI. You can also check the EAI Queue (under Application
Administration – Integration) for a status and a copy of the XML that
you attempted to import.

 

The
file deployment mode is also supported via the server manager (srvrmgr)
command line which optimizes the import operation. With one srvrmgr
command, you can import multiple files.

 

Common ADM Error Messages

 

Below
is a list of common ADM error messages. Make sure to search SupportWeb
with the error message and check for the latest ADM alerts as well.

 

These
error messages may appear on the GUI or in a log file. For a listing of
places to check for log files that would contain ADM related errors,
see Figure 1.

 

Table 4 - Common ADM Error Messages and Symptoms

 

An error occurred exporting to file. Please make sure the path <path value> points to a valid directory which has enough space and is writable by the application process owner (SBL-SVC-00255)

SBL-SRQ-00103: Unable to find definition of component WfProcMgr

SBL-SVC-00232: The schema and SRF of the source environment and the target environment must be of the same version.

Step '<?>' references non-existent error symbol '<?>'.(SBL-BPR-00186)

EAI Queue Entry Always Created During File Import

Unable To Deploy: Target Server Path is a required field. Please enter a value for the field. (SBL-DAT-00498)

Deployment Failed: “[Microsoft][ODBC Driver Manager] Invalid cursor state”

Cannot connect to the server (SBL-EAI-04115). An error occurred connecting to the Target System.

SBL-BPR-00158: Cannot execute workflow process definition 'UDA Batch Deployement'

ObjMgrSRFLog Warning...(objdef.cpp (2192)) SBL-DAT-00144: Could not find 'Import Object' named 'EMT Session'

Multiple matches found for instance of integration component '%1' using search specification '%2' in the business component '%3', based on user key '%4'

LAST_UPD_BY Field Does Not Contain Correct Values

Task Status Completed but Data Not Imported

"There were more rows than could be returned. Please refine your query to bring back fewer rows (SBL-DAT-00500) (SBL-EAI-04376)

View: UDA Project Administration View does not contain applet: EMT Project Form Applet. (SBL-SVC-00254)

LOV Parent-Child Relationship Is Not Established

 

 

An
error occurred exporting to file. Please make sure the path <path
value> points to a valid directory which has enough space and is
writable by the application process owner (SBL-SVC-00255)

 

Symptom or Error Message

 

You received the following error when exporting to a file:

 

An
error occurred exporting to file. Please make sure the path <path
value> points to a valid directory which has enough space and is
writable by the application process owner (SBL-SVC-00255)

 

Cause

 

The export path specified is not a valid directory name or is inaccessible from the machine where the ADM process is running.

 

Diagnostic Steps

 

Verify that the file path given is valid and can be accessed from the machine where the ADM process is running.

 

Solution

 

The
export path should be a shared network resource. If deploying to a file
using a dedicated client, specify an export path is that is relative to
the dedicated client. For example, if you are on your local Windows
machine, you can specify d:\temp as your export path.

 

If
deploying to a file using a zero footprint client, specify an export
path is relative to the Siebel server where the object manager is
running.  For example, if you are using the thin client, and connecting
to a Siebel server running on Solaris, you need to specify a network
path that is valid for the Solaris server, i.e. /tmp.

 

 

SBL-SRQ-00103: Unable to find definition of component WfProcMgr

 

Symptom or Error Message

 

After
clicking Deploy and entering the correct password, the deployment
session fails. The following error messages shows up in the Siebel
component log:

 

SBL-SRQ-00103: Unable to find definition of component WfProcMgr

 

In the ADM log or on the Siebel client, you may see this error message:

 

Error encountered at workflow "<?>", step "<?>"

- No change/update is in effect.(SBL-EAI-04442)

 

Cause

 

The
Workflow Process Manager Server component definition has not been
synchronized from the Server Manager screen. When you synchronize
components, the Siebel server updates information about your Enterprise
in the S_SRM_ACTION table.

 

Diagnostic Steps

 

1. Navigate to Sitemap > Administration - Server Configuration > Enterprises > Synchronize.

 

2. The
   middle applet (Batch Component Admin) should contain a list of server
   components. If the list is empty, synchronization has not been done.

 

Solution

 

In
the source and target environments, start a Siebel Client. Then
navigate to Sitemap > Administration - Server Configuration >
Enterprises > Synchronize, click Synchronize.

 

 

SBL-SVC-00232: The schema and SRF of the source environment and the target environment must be of the same version.

 

Symptom or Error Message

 

The deployment session fails with this error:

 

SBL-SVC-00232: The schema and SRF of the source environment and the target environment must be of the same version.

 

Cause

 

In
Siebel 7.7, ADM checks the Siebel SRF and schema versions of the target
environment against that of the source environment. If either the SRF
or the custom schema versions are different, you will get the error.

 

Bug 10477353 has been logged to address this product defect. It has been fixed in Siebel Fix Pack 7.7.2.1. 

 

The
new behavior is that SRF version will not be validated. The custom
schema version checking will be skipped but the major, minor and
vertical schema versions are still checked. However, if the SRFs between
the target and source environments do not have matching integration
objects, the deployment would still fail.

 

Solution

 

1. Contact
   Siebel Technical Support to request the latest available 7.7.2.x Fix
   Pack. Install the fix pack on your target and source Siebel application
   environments.

 

2. If
   you are not able to install the fix pack, a manual workaround is
   available. It is to deploy using Export Files so you can modify the XML
   attributes. Here is how to modify the XML:

 

1. Determine the schema and srf versions for the target system.

 

2. Deploy
   any file on the target System (you will not need to import this project
   into any system.) Then open up the file you deployed in notepad and
   copy out the lines containing the SchemaVersion and SRFVersion. It will
   look something like this (with different values in double quotes):

 

SchemaVersion="41.57.0.69" SRFVersion="36|1074164158|1087259477"

 

3. Modify the Export file.

 

4. Open
   up the XML file created from your source system. Then cut and paste the
   Schema and SRF string from the target system’s XML into your source
   system’s XML file. When you save the source system XML file, make sure
   you retain the original encoding of the XML document (utf-8).

 

NOTE: Other modifications to the XML content are not recommended unless otherwise directed by Siebel Technical Support.

 

If
you require a workaround for online deployments, please contact Siebel
Technical Support for assistance with modifying the UDA Deployment
workflow process.

 

 

Step '<?>' references non-existent error symbol '<?>'.(SBL-BPR-00186)

 

Symptom or Error Message

 

When deploying a session using the command line interface, the status of the deployment session fails with the following errors:

 

We detected an Error which may have occurred for one or more of the following reasons:

Step '<?>' references non-existent error symbol '<?>'.(SBL-BPR-00186)

 

You may see this error in the object manager log:

 

SBL-GEN-00000: Unable to load message 0xffff

 

Cause

 

Command line deployment using on-line mode is not supported

 

Solution

 

In
order to deploy in command line mode, the session must be configured to
export to a file by checking the Export to File flag. Batch deployment
using on-line mode is not supported.

 

 

EAI Queue Entry Always Created During File Import

 

Symptom or Error Message

 

An EAI queue entry is always created when performing a file import regardless of the Business Component User Property value.

 

Cause

 

This is an expected behavior for the standard ADM configuration.

 

Solution

 

To stop entry generation in the EAI Queue, set the User Property Use EAI Queue to Never on the EMT Session business component.

 

For more information about the EAI Queue, refer to Siebel Bookshelf version 7.7 > Siebel Connector for SAP R/3.

 

 

Unable To Deploy: Target Server Path is a required field. Please enter a value for the field. (SBL-DAT-00498)

 

Symptom or Error Message

 

You are not able to deploy to a file. When you click Deploy, you may see this message:

 

Target Server Path is a required field. Please enter a value for the field. (SBL-DAT-00498)

 

Cause

 

The Export to File box must be checked to deploy to a file.

 

Solution

 

Check the Export to File box in the ADM Session.

 

If
the box is grayed out, you need to recreate a new ADM Project and check
the Export to File box for the new ADM Project. Then enable the new ADM
Project and redeploy.

 

 

Deployment Failed: “[Microsoft][ODBC Driver Manager] Invalid cursor state”

 

Symptom or Error Message

 

After clicking Deploy, the status changes to Deployment Failed. The following error message shows up in the SRProc.log file:

 

"[Microsoft][ODBC Driver Manager] Invalid cursor state"

 

Cause

 

1. The database is running out of the cursors.

 

2. There are too many connected users.

 

Diagnostic Steps

 

Check the number of the cursors in the database and make sure it complies with Siebel system requirements.

 

Solution

 

If the number of cursors is too low, increase the cursor number and run the deployment again.

 

 

Cannot connect to the server (SBL-EAI-04115). An error occurred connecting to the Target System.

 

Symptom or Error Message

 

When submitting an online deployment, you receive the following error:

 

Cannot
connect to the server (SBL-EAI-04115). An error occurred connecting to
the Target System. Please verify the connection information.
(SBL-SVC-00252)

 

Cause

 

The HTTP session from the source to the target could not be started.

 

Diagnostic Steps

 

1. Check that you have supplied a valid Siebel URL for the target system.

 

2. Check that you have typed in a valid username and password for the target system

 

3. Check
   that the EAI object manager on the target system is online. You can
   verify that the EAI object manager on the target system is online by
   using the statspage with this URL:
   http://<webserver>:<port>/eai_enu/_stats.swe (substitute
   <webserver> and <port> with values for your environment). If
   the stats page comes up, you have verified that you are able to connect
   to the EAI Object manager and it is online.

 

4. Check
   that the source and target environments have network connectivity. For
   example, make sure you can ping the target webserver from the source
   Siebel server physical machine.

 

Solution

 

1. Fix any invalid arguments supplied and recreate the deployment session.

 

2. Make sure that the EAIObjMgr is online on the target system.

 

3. If
   there are network problems, check with your network administrator to
   resolve the problems (e.g., name resolution problems, firewalls in
   place).

 

 

SBL-BPR-00158: Cannot execute workflow process definition 'UDA Batch Deployement'

 

Symptom or Error Message

 

When executing a batch deployment, you get the error:

 

SBL-BPR-00158: Cannot execute workflow process definition 'UDA Batch Deployement'

 

Cause

 

The workflow process name is not spelled correctly or the workflow process is not activated in the Siebel Client.

 

Diagnostic Steps

 

1. Check
   the spelling of your workflow process. In the symptom above,
   Deployement is misspelled (an extra 'e' between the 'y' and the 'm').

 

2. In
   Siebel Tools, check that workflow processes have a status of Completed.
   In the Siebel client, verify the same workflow processes have a status
   of Active.

 

Solution

 

1. Resubmit your workflow process task with the correct spelling.

 

2. If
   you have enabled a workflow process in the Siebel client, stop the
   workflow process manager component and restart it. Resubmit your job.

 

 

ObjMgrSRFLog Warning...(objdef.cpp (2192)) SBL-DAT-00144: Could not find 'Import Object' named 'EMT Session'

 

Symptom or Error Message

 

When you enable component event logging in the Siebel server components, you see messages like these:

 

ObjMgrSRFLog     
Warning    ...    (objdef.cpp (2192)) SBL-DAT-00144: Could not find
'Import Object' named 'EMT Session'. This object is inactive or
nonexistent.

 

Cause

 

These
are warning messages, and they are benign. You can ignore those
messages. If the value after the component event is not Warning, then
you should investigate if the error is fatal.

 

 

Multiple
matches found for instance of integration component '%1' using search
specification '%2' in the business component '%3', based on user key
'%4'

 

Symptom or Error Message

 

When deploying all the out of the box LOVs, you get this error:

 

Multiple
matches found for instance of integration component '%1' using search
specification '%2' in the business component '%3', based on user key
'%4'.

 

Cause

 

The Siebel seed data has duplicate values for LOVs.

 

Change Request 12-MPWXD3  has been logged to address this product defect.

 

Diagnostic Steps

 

Log into the database and run the following SQL statement to see if you have duplicate seed data:

 

select TYPE, NAME from S_LST_OF_VAL

where type = ‘LOV_TYPE’

group by TYPE, NAME

having count(*) > 1

 

Solution

 

Log
on a Siebel Client, and go to the LOV Views. Query for the LOV Types
you found running the SQL Query in the diagnostic steps. For each
duplicate pair, change the display value for one of the records to make
the record unique.

 

 

LAST_UPD_BY Field Does Not Contain Correct Values

 

Symptom or Error Message

 

After
migrating data from the source application to the target application
with different users, records are always inserted as SADMIN user ID. The
LAST_UPD_BY field does not contain correct values.

 

Cause

 

Data
is inserted into the target application using the Server Request Broker
(SRB) and Server Request Processor components (SRP). The user stamp on
the inserted records will be the user name set for the SRB/SRP
components (typically SADMIN), not the user name supplied from the
source application.

 

Solution

 

Create a new user ID with the same privilege as SADMIN and update the SRB/SRP components to use that new user ID.

 

 

"There were more rows than could be returned. Please refine your query to bring back fewer rows (SBL-DAT-00500) (SBL-EAI-04376)

 

Symptom or Error Message

 

When exporting data to a file, you receive the following error message:

 

We detected an Error which may have occurred for one or more of the following reasons:

Method
'NextRecord' of business component 'Feature Access' (integration
component 'Feature Access') returned the following error: "There were
more rows than could be returned. Please refine your query to bring back
fewer rows (SBL-DAT-00500) (SBL-EAI-04376)

 

Cause

 

There is a 10K limit on the EAI transport.

 

Solution

 

Specify a search specification such as [Name] not like 'A* to reduce the number of records returned to less than 10,000.

 

If
you are not in a production environment and would like to bypass the
10K limit, it is possible to do so. However, please bear in mind that
there is a potential for large memory usage of the Siebel server
component.

 

To
bypass the default 10,000-record limit, set the value for the parameter
"DSMaxFetchArraySize" under the "InfraDatasources" named sub-system to
the number of records you expect to export. Note that this param is for a
given data source and would impact all components that share the same
data source so we only advise you set this value immediately prior to
your export and reset it to the default after your export.

 

 

Task Status Completed but Data Not Imported

 

Symptom or Error Message

 

When
deploying sessions using the command line interface, the status of the
workflow process task is completed. However the data has not been
imported to the target environment.

 

Cause

 

1. The UDA Batch Import and UDA Batch Deployment workflow processes have not been deployed properly.

 

2. The FileExportPath and FileImportPath process properties are not valid.

 

Diagnostic Steps

 

1. In
   Siebel Tools, check that UDA Batch Import and UDA Batch Deployment
   workflow processes have a status of Completed. In the Siebel client,
   verify the same workflow processes have a status of Active.

 

2. Confirm the workflow processes have the correct FileExportPath and FileImportPath process property values.

 

Solution

 

1. Deploy
   the UDA Batch Import and UDA Batch Deployment workflow processes in
   Siebel Tools. Activate the workflow processes in the Siebel Client.

 

2. When
   exporting the file, verify the FileExportPath process property is set
   correctly for the workflow process UDA Batch Deployment. When importing
   the file, verify that the FileImportPath for the UDA Batch Import
   workflow process has a valid value. The values should be the directories
   which will contain the exported and imported files respectively. Both
   values can point to the same location.

 

NOTE:
For more information about how to deploy using the command line
interface, refer to Siebel Bookshelf version 7.7 > Going Live with
Siebel eBusiness Applications > Migrating Customizations Between
Applications > Deploying Sessions Using Command-Line Interface.

 

For
more information about deploying in batch mode (running the workflow
process), refer to Siebel Bookshelf version 7.7 > Going Live with
Siebel eBusiness Applications > Migrating Customizations Between
Applications > Reviewing the ADM Data Migration.

 

 

View: UDA Project Administration View does not contain applet: EMT Project Form Applet. (SBL-SVC-00254)

 

Symptom or Error Message

 

View: UDA Project Administration View does not contain applet: EMT Project Form Applet. (SBL-SVC-00254)

 

Cause

 

The applet might be missing in View: UDA Project Administration View

 

Diagnostic Steps

 

In Siebel Tools, query for the View UDA Project Administration View.

 

Check for all the View Web Template Item applets. Verify if the EMT Project Form Applet is there.

 

Solution

 

In
Siebel Tools navigate to View and query for UDA Project Administration
View and then add a View with the following information:

 

Web Template Item

Name = "EMT Project Form Applet" applet

Item Identifier = 3 or next number

Applet Value = "EMT Project Form Applet"

Applet Mode = "Edit"

 

 

LOV Parent-Child Relationship Is Not Established

 

Symptom or Error Message

 

When
deploying dependent data types, such as hierarchical LOVs with the
LOV-HierParent data type, both records are successfully imported in the
target system, but the parent-child relationship is not established. For
LOVs, after the first deployment, the child LOV does not show the
parent LOV. When you redeploy the project a second time, then the
parent-child relationship is established.

 

Cause

 

For
dependent data types, ADM will deploy the child data type before the
parent data type. When ADM deploys the child data, the parent does not
yet exist so the EAI Siebel Adapter cannot set the relationship on the
child to point to the parent. Hence, after the first deployment, while
both data types are successfully deployed, the relationship between the
two records is not established.

 

Solution

 

This
is the intended behavior of ADM that all hierarchical data must be
imported twice. When deploying a child record, ADM will not error out if
the parent record does not exist because the picklist validation is
disabled.

 

When
an LOV record with a reference to a parent Language Independent Code
(LIC) value is being inserted, that parent LIC value must already be
present in the target system for the reference to be successfully set.
However, since the Parent LIC value is in itself another LOV record, the
only way to make sure that all the references are successfully
established is to import the LOV values using two dependent data types
both are LOV data types. Internally this will cause two deployment
operations to occur, once per session item. See Figure 5 for a logical
description of what happens.

 

Import pass #1 based on the LOV-HierChild session item:
all LOVs will be inserted successfully. For the child LOVs that
reference a parent LIC, the parent LIC field will be left blank. The UDA
List of Values integration component has been configured to ignore
errors on self referenced fields which are bounded to a picklist.

 

Import pass #2 based on the LOV-HierParent session item:
the same LOVs will be updated. However, now any Parent LIC values
referenced in the record being imported is already present in the target
DB. So therefore, second import will update the LOV records previously
upserted from the first deployment with the correct parent LIC value.

 

In
the case where the parent and child LOVs are of different LOV Types,
you can deploy the data in one deployment session by using the
deployment filter. Since the ADM child data type (LOV-HierChild) is
always deployed first, if you set the deployment filter for the child
ADM data type to find the record for the parent LOV, the parent LOV can
be inserted before the child LOV. Then set the deployment filter for the
parent ADM data type (LOV-HierParent) to find the child LOV deployment
record. See Figure 6 for the logical description of what happens.

 

NOTE:
If you are deploying LOVs where the LOV child and parent are of
different LOV types, please have a new service request opened referring
to Bug 10473596 , Bug 10474105, and Bug 10498207 in
order to get more information on how to obtain updated SIFs. Without
the updated SIFs compiled into your SRF, you will not be able to deploy
LOV data if the LOV Types are different.

 

Figure 5 - Hierarchical LOV Deployment with LOVs of the Same LOV Type

 

 

 

Figure 6 - Hierarchical LOV Deployment with LOVs of Different LOV Type

 

 

Applies to:

Siebel CRM Service, SPE - Version 8.1.1.8 SIA [23012] and later
Information in this document applies to any platform.

Symptoms

While using ADM to migrate data, "The schema of the source
environment and the target environment must be of the same
version.(SBL-SVC-00232)". error message is seen if the schema of source
and target environment are different.


If there are multipe schema changes on an environment, the schema
version of the environment would be higher than the other and it is very
hard to get the schema versions in sync.

Cause

 Siebel Product defect 15862953 has been logged to disable schema version checking when deploying data using ADM.

Solution

 This has been reproduced in vanilla and defect 15862953 has been logged to address this.


 As a workaround, the schema version information in the xml file generated can be manually edited to be same as the target env.