Skip to main content
ComponentsEngineJS ProfilerMobile AppRPA Bot RecorderRUM JS
Availability2014.1 or later

Prerequisites

Setup needed before recording

Define success before recording

Pick what proves success

Import the scenario

Naming and importing recordings

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
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
  • 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.
  • 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.

​
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. 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
  • 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:

​
Select the execution location

Choose an Engine representing the path you want to test. 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.
  • 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. Configure alerts for:
  • Complete scenario failure
  • Login failure
  • Missing element
  • Assertion failure
  • Step timeout
  • Scenario timeout
  • 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
  • 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
  • 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
  • Background workflows
  • Test-data dependencies
  • Maintenance periods

Dashboard & Reports

Dashboard & Reports

AI

Insights & Recommendations

Analytics

More Analytics Features

Automation

More Automation Features

​
Get Help

Contact GermainUX Support

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.

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.