> ## Documentation Index
> Fetch the complete documentation index at: https://docs.germainux.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Synthetic User Scenario for Oracle Siebel CRM (Recording)

> The GermainUX RPA Bot Recorder creates Selenium-based synthetic user scenarios for Oracle Siebel CRM.

Components
[`Engine`](https://docs.germainux.com/main/germain-ux-engine)
[`JS Profiler`](https://docs.germainux.com/main/germain-ux-js-profiler)
[`Mobile App`](https://docs.germainux.com/main/germain-ux-mobile-app)
[`RPA Bot Recorder`](https://docs.germainux.com/main/germain-ux-rpa-bot-recorder)
[`RUM JS`](https://docs.germainux.com/main/germain-ux-rum-js)

Availability
2014.1 or later

> [card] [Prerequisites](#prerequisites)
>
> Setup needed before recording

> [card] [Define success before recording](#define-success-before-recording)
>
> Pick what proves success

> [card] [Import the scenario](#import-the-scenario)
>
> Naming and importing recordings

> [card] [Troubleshooting](#troubleshooting)
>
> Fix common recording problems

**Record a Synthetic User Scenario for Oracle Siebel CRM**

The GermainUX RPA Bot Recorder creates Selenium-based synthetic user scenarios for Oracle Siebel CRM.

Once imported into GermainUX, a scenario can run continuously from one or more locations to detect availability, performance, authentication, and workflow problems before they affect real users.

**Recording component:** GermainUX RPA Bot Recorder \
 **Execution component:** GermainUX Engine \
 **Feature availability:** GermainUX 2018.4 or later

> [!NOTE]
>
> This feature records and executes synthetic Siebel workflows. It is not an eScript debugger.

## What a synthetic scenario can validate

A Siebel synthetic scenario can:

* Sign in
* Open an application, screen, view, or applet
* Search for a record
* Open a known Account, Contact, Asset, or Service Request
* Create or update a safe test record
* Execute a query

> [accordion] Show all 10
>
> * Submit a workflow
> * Validate a confirmation or expected value
> * Measure individual workflow steps
> * Sign out

Running these scenarios at a defined frequency helps verify that Siebel remains available and usable from the selected execution location.

## Prerequisites

Before recording:

* Install the GermainUX RPA Bot Recorder extension.
* Use a supported Chrome or Microsoft Edge browser.
* Confirm access to the target Siebel environment.
* Create a dedicated synthetic Siebel account.
* Prepare predictable test data.
* Define the expected workflow outcome.

> [accordion] Show all 10
>
> * Identify how created data will be removed or reset.
> * Deploy a GermainUX Engine for unattended execution.
> * Confirm that the Engine can reach Siebel and its identity provider.
> * Review authentication, privacy, and production-safety requirements.

See [RPA Bot Recorder Deployment for Oracle Siebel CRM](https://docs.germainux.com/main/rpa-bot-recorder-deployment-for-oracle-siebel-crm.md).

## Select a workflow

Create one focused scenario for each critical user journey.

Good candidates include:

* Siebel login
* Account search
* Contact lookup
* Service Request creation
* Opportunity update
* Order submission
* Critical integration-dependent action
* Logout

Avoid one long scenario covering several unrelated workflows. Short scenarios are easier to maintain, diagnose, and assign to the responsible team.

## Define success before recording

Document what proves that the workflow succeeded.

| Workflow | Reliable success condition |
| - | - |
| Login | Expected Siebel application or home view appears |
| Search | Known record appears in the result list |
| Create record | Confirmation appears and the record receives an identifier |
| Update record | Updated value appears after the save completes |
| Submit workflow | Expected final status or confirmation appears |
| Integration action | Expected response or synchronized value appears |
| Logout | Login page or signed-out state appears |

Navigation alone does not prove that the underlying business transaction succeeded.

## Open synthetic configuration

In GermainUX, go to:

**Workspace > Automation > Click**

Create a new synthetic scenario.

GermainUX displays the available creation methods. Choose the RPA Bot Recorder option for the fastest way to create a new browser scenario. Other available options can be used when an existing script is available or when the scenario must be created manually.

## Prepare the browser session

Before starting the recording:

* Close unrelated browser tabs.
* Open a new browser session.
* Navigate to a consistent starting URL.
* Confirm that the recorder recognizes the page.
* Prepare the synthetic credentials.
* Reset the test data to its expected initial state.
* Disable browser features that would not exist during unattended execution.
* Start from the login page if authentication is part of the scenario.

Do not rely on an existing authenticated session unless authentication is intentionally excluded from the test.

## Record the scenario

**1. Open the target Siebel environment**

**2. Start a new recording in the RPA Bot Recorder**

**3. Perform the workflow exactly as a user would**

**4. Pause for pages and controls to become ready before interacting**

**5. Add validations for the expected outcome**

**6. Sign out when logout is part of the scenario**

**7. Stop the recording**

**8. Review the generated Selenium steps**

**9. Remove unnecessary actions**

**10. Save or export the scenario**

Record only the steps required to validate the workflow.

## Review Siebel selectors

Siebel Open UI can generate dynamic elements and identifiers. A selector that works during recording may fail after a page refresh or release.

Prefer selectors based on:

* Stable element IDs
* Stable names
* Consistent attributes
* Dedicated test attributes
* Reliable relationships to stable parent elements
* Stable Siebel control properties

Avoid selectors based only on:

* Visual position
* Row number
* Long DOM paths
* Generated class names
* Temporary identifiers
* Frequently changing text
* Current record order

Test selectors across multiple sessions before enabling a schedule.

## Handle screens, views, and applets

Siebel workflows can update part of the interface without performing a complete page load.

After navigation, wait for the expected Siebel context, such as:

* Screen
* View
* Applet
* Control
* Record
* Confirmation
* Status value

Do not assume that a URL change alone identifies the active Siebel view.

## Use condition-based waits

Replace fixed delays with waits for meaningful conditions.

Wait for:

* An element to become visible
* A field to become available
* A button to become enabled
* A progress indicator to disappear
* A view or applet to finish loading
* A record to appear

> [accordion] Show all 9
>
> * A confirmation message to display
> * A background request to complete
> * A dialog or new window to open

Condition-based waits make the scenario more reliable when response times vary.

Use fixed waits only when no reliable application condition is available, and keep them as short as practical.

## Add assertions

Add assertions that validate the business outcome.

Examples include:

* Correct screen or view is displayed
* Known Account appears in results
* Service Request number is generated
* Status changes to the expected value
* Confirmation message appears
* Required content is present
* Error message is absent
* Integration-produced value appears

A scenario without assertions may report success even when the business transaction failed.

## Define transaction steps

Divide the scenario into meaningful transactions so GermainUX can measure each part independently.

For example:

**1. Login**

**2. Open Service Requests**

**3. Search for customer**

**4. Create Service Request**

**5. Save**

**6. Validate result**

**7. Logout**

Use business-readable names. Avoid naming steps after technical Selenium actions such as `clickElement1`.

Step measurements help determine whether degradation occurs during authentication, navigation, search, saving, or another part of the workflow.

## Protect credentials

The recorder can capture values entered during the session.

Do not leave these values embedded in the script:

* Passwords
* Authentication tokens
* API keys
* Session identifiers
* Customer information
* Payment information
* Protected health information
* Other confidential data

Replace credentials with references to the GermainUX credential or secret-management configuration.

Use a dedicated, least-privilege synthetic account. Do not use a real user’s account.

## Authentication considerations

Unattended scenarios can be affected by:

* MFA
* CAPTCHA
* Hardware tokens
* Interactive approval
* Conditional-access policies
* SSO session expiration
* Password rotation
* Account lockout

Work with the identity and security teams to create an approved automation-compatible authentication flow.

Do not bypass required security controls without explicit authorization.

## Manage test data

Synthetic scenarios must not damage or pollute production data.

Use:

* Dedicated synthetic records
* Clearly identifiable test values
* Predictable starting data
* Idempotent operations where possible
* A cleanup step or scheduled cleanup job

Avoid scenarios that:

* Modify real customer records
* Submit real orders
* Trigger real payments
* Send customer communications
* Create irreversible transactions
* Affect operational reporting

If the scenario creates a record, define how and when that record will be removed or reused.

## Import the scenario

After reviewing the recording:

**1. Import it into GermainUX**

**2. Enter a descriptive name**

**3. Select the Siebel application and environment**

**4. Select the execution Engine**

**5. Configure credentials and variables**

**6. Configure the browser and runtime**

**7. Set the timeout**

**8. Configure transaction steps**

**9. Configure success and failure conditions**

**10. Run the scenario manually**

**11. Review screenshots, steps, timings, and errors**

**12. Enable recurring execution only after validation succeeds**

A useful name identifies the application, environment, and workflow:

```text theme={null}
Siebel-Production-Login-Account-Search
```

## Select the execution location

Choose an Engine representing the path you want to test.

| Location | What it validates |
| - | - |
| Data center | Core Siebel and infrastructure availability |
| Corporate office | User access through the corporate network |
| Regional location | Regional latency and availability |
| External or cloud location | Internet-facing access |
| Multiple locations | Differences between user populations and network paths |

The Engine must be able to reach:

* Siebel CRM
* Authentication services
* Required proxies
* DNS and certificate services
* Integrations used by the workflow
* GermainUX

## Validate unattended execution

A scenario that succeeds in the recorder may fail on the Engine.

Confirm that:

* The Engine can reach the Siebel URL.
* Proxy and firewall rules permit access.
* The browser and driver are compatible.
* Runtime credentials are available.
* The scenario starts from a clean browser state.
* Screen resolution does not hide required controls.

> [accordion] Show all 10
>
> * Pop-ups, frames, downloads, and windows are handled.
> * Test data is available.
> * The expected business outcome is validated.
> * Cleanup completes successfully.

Run several consecutive tests before enabling the schedule.

## Configure the schedule

Select a frequency appropriate to the workflow’s importance and impact.

Consider:

* Business hours
* Criticality
* Expected recovery objective
* Load generated by the scenario
* Number of execution locations
* Maintenance periods
* Account concurrency limitations

Avoid running multiple state-changing scenarios simultaneously with the same account.

## Configure KPIs and alerts

Synthetic execution populates the Siebel synthetic transaction KPIs.

See [KPIs for Oracle Siebel CRM](https://docs.germainux.com/main/oracle-siebel-crm-monitoring-kpis.md).

Configure alerts for:

* Complete scenario failure
* Login failure
* Missing element
* Assertion failure
* Step timeout
* Scenario timeout

> [accordion] Show all 9
>
> * Step duration above SLA
> * Complete duration above SLA
> * Consecutive failures

For potentially transient conditions, consider requiring more than one failed execution. Continue to alert immediately for critical availability failures when operationally appropriate.

## Dashboards

Go to:

**Workspace > Left Menu > Dashboards > All**

Search for:

* **Siebel Availability**
* Other dashboards beginning with **Siebel**

Useful synthetic visualizations include:

* Availability percentage
* Scenario duration
* Step duration
* Failures over time
* Results by execution location
* Failure reason
* SLA violations
* Recent screenshots

## Maintain the scenario

Review and retest the scenario after:

* A Siebel release
* A browser update
* A browser-driver update
* An authentication change
* A screen, view, applet, or control change
* A workflow change

> [accordion] Show all 9
>
> * A test-data change
> * A synthetic account change
> * Repeated intermittent failures

Include synthetic-scenario validation in the Siebel release process.

## Troubleshooting

### The recorder does not capture actions

Verify that:

* The extension is installed and enabled.
* The browser is supported.
* The extension can access the Siebel domain.
* Browser policy does not block it.
* The page was reloaded after installation.
* The control is not inside an unsupported browser context.

### Replay cannot locate an element

Review:

* Selector stability
* Generated IDs
* View and applet readiness
* Frames and dialogs
* Whether a wait condition is missing
* Whether the record order changed
* Whether the browser resolution differs

### The scenario works locally but fails on the Engine

Compare:

* Browser and driver versions
* Screen resolution
* Proxy and firewall access
* DNS
* TLS certificates
* Authentication flow

> [accordion] Show all 11
>
> * Credentials
> * Locale and time zone
> * Test data
> * Siebel URL
> * Browser policies

### The scenario generates intermittent alerts

Review:

* Fixed delays
* Condition-based waits
* Dynamic selectors
* Network latency
* Account contention
* Competing scenarios

> [accordion] Show all 9
>
> * Background workflows
> * Test-data dependencies
> * Maintenance periods

## Related Documentation

> [card] [Dashboard & Reports](https://docs.germainux.com/main/dashboard-and-report.md)
>
> Dashboard & Reports

> [card] [AI](https://docs.germainux.com/main/ai-driven-insights.md)
>
> Insights & Recommendations

> [card] [Analytics](https://docs.germainux.com/main/analytics.md)
>
> More Analytics Features

> [card] [Automation](https://docs.germainux.com/main/automation.md)
>
> More Automation Features

## Get Help

> [card] [Contact GermainUX Support](https://docs.germainux.com/main/support.md)
>
> The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

> [card] Can't find what you need?
>
> Search all GermainUX docs with **Ctrl + K**, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.