Skip to main content
ComponentsEngine
Availability2018.2 or later

What synthetic monitoring provides

Proactive checks of Siebel workflows

Prepare the Siebel scenario

Document purpose and owner

Choose an execution location

Engine close to the path

Troubleshooting

Resolve common scenario problems

​
Overview

The GermainUX RPA Bot Recorder is a browser extension used to create Selenium-based synthetic user scenarios for Oracle Siebel CRM. It records a user’s interactions with Siebel and converts them into a script that can be imported, executed, scheduled, and monitored in GermainUX.
The RPA Bot Recorder creates the scenario. GermainUX-Engine imports, executes, monitors, and schedules it.

​
What synthetic monitoring provides

Use recorded Siebel scenarios to:
  • Test critical workflows continuously
  • Detect availability or performance problems before users report them
  • Measure login, navigation, search, and transaction response times
  • Validate business processes after a Siebel release
  • Detect broken views, applets, fields, buttons, or integrations
  • Automate browser-based regression and QA tests
  • Confirm that Siebel is accessible from a specific location
  • Generate alerts when a workflow fails or exceeds an SLA

​
Example Siebel scenarios

Create separate scenarios for important user journeys, such as:
  • Sign in to Siebel
  • Open a specific application or screen
  • Search for an Account, Contact, Asset, or Service Request
  • Open a customer record
  • Create or update a Service Request
  • Create or update an Opportunity
  • Navigate between views and applets
  • Execute a query
  • Submit an approval or workflow
  • Validate an integration-dependent action
  • Sign out
Keep each scenario focused on one business outcome. Short scenarios are generally easier to maintain and troubleshoot than one long script covering unrelated processes.

​
Deployment components

  • RPA Bot Recorder extension: Records the Siebel workflow in Chrome or Microsoft Edge.
  • GermainUX: Imports, configures, schedules, monitors, and analyzes the scenario.
  • GermainUX Engine: Executes the scenario from the selected monitoring location.
  • Browser and driver: Run the Selenium scenario on the Engine host.
  • Synthetic Siebel account: Authenticates and performs the recorded workflow.
The recorder does not need to remain installed on the Engine host unless that computer is also used to create or edit scenarios.

​
Requirements

Before recording a Siebel scenario, prepare:
  • Supported browser: A supported version of Google Chrome or Microsoft Edge
  • Recorder extension: The GermainUX RPA Bot Recorder extension
  • Siebel access: Access to the Siebel environment and workflow being tested
  • Test account: A dedicated Siebel account with the required permissions
  • Test data: Predictable data that the scenario can safely read, create, update, or remove
  • GermainUX environment: A GermainUX environment into which the scenario can be imported
  • Execution Engine: A connected Engine with access to the monitored Siebel environment
  • Browser runtime: A compatible browser and driver on the execution host
  • Network access: Required DNS, proxy, firewall, TLS, and identity-provider connectivity
Avoid using real customer accounts or production data when a dedicated test environment is available.

​
Install the recorder

Install the GermainUX RPA Bot Recorder extension in Chrome or Microsoft Edge. If browser extensions are centrally controlled, ask the browser or endpoint administrator to approve and deploy the extension using the organization’s managed browser policies. After installation:
1

Confirm that the recorder appears in the browser toolbar

2

Grant it access only to the Siebel sites you intend to record

3

Open or reload Oracle Siebel CRM

4

Verify that the recorder detects the current page

5

Confirm that the intended Siebel domain is allowed by the extension

For general installation information, see GermainUX RPA Bot Recorder.

​
Prepare the Siebel scenario

Before recording:
1

Select one critical workflow

2

Define its starting point

3

Identify the expected successful outcome

4

Prepare a dedicated synthetic user

5

Prepare predictable test records

6

Determine whether the scenario creates or changes data

7

Define how created data will be cleaned up

8

Confirm that the workflow does not require an unsupported interactive authentication step

9

Close unrelated browser tabs and applications

10

Start from a new browser session when authentication is part of the test

Document the business purpose of the scenario and the team responsible for maintaining it.

​
Record a scenario

To record a Siebel workflow:
1

Open Siebel CRM at a consistent starting page

2

Start a new recording in the RPA Bot Recorder

3

Perform the workflow exactly as a user would

4

Add validation steps that confirm the expected outcome

5

Stop the recording

6

Review the generated Selenium steps

7

Remove unnecessary navigation or duplicate actions

8

Replace sensitive values with credential or configuration references

9

Save or export the scenario

10

Import it into GermainUX

Record only the actions required to validate the workflow.

​
Review selectors

Siebel Open UI pages can contain dynamic elements. Review the selectors generated by the recorder before scheduling the scenario. Prefer stable selectors based on:
  • Unique element identifiers
  • Stable names or attributes
  • Dedicated test attributes
  • Consistent Siebel control properties
  • A reliable relationship to a stable parent element
Avoid selectors based only on:
  • Visual position
  • Row number
  • Long DOM paths
  • Generated class names
  • Temporary identifiers
  • Text that changes frequently
  • A specific record order
Custom views, applets, embedded frames, pop-up windows, and asynchronously created elements may require manual adjustments.

​
Add condition-based waits

Do not assume that every Siebel page or operation completes within a fixed amount of time. Configure the scenario to wait for a required condition, such as:
  • A view or applet becoming visible
  • A field becoming available
  • A button becoming enabled
  • A progress indicator disappearing
  • A record appearing in a list
  • A confirmation message appearing
  • A background request completing
  • A new window or dialog opening
  • The expected page or route loading
Condition-based waits make scenarios more reliable across environments and during periods of varying server response time.

​
Add business validations

Completing the recorded clicks does not prove that the business process succeeded. Add assertions that verify the expected result. For example:
  • The correct Siebel screen or view is displayed.
  • The expected Account, Contact, or Service Request is present.
  • A record was created or updated.
  • A confirmation message appears.
  • A required field contains the expected value.
  • A workflow reaches the intended status.
  • An expected control is enabled.
  • An error message is absent.
Choose assertions that represent the actual business outcome rather than incidental visual details.

​
Protect credentials and sensitive data

The recorder may capture values entered during recording. Do not embed the following information directly in a recorded scenario:
  • Real user passwords
  • API keys or authentication tokens
  • Customer information
  • Payment information
  • Protected health information
  • Personally identifiable information
  • Confidential production data
  • Session identifiers
Use a dedicated synthetic account and store its credentials through the credential-management mechanism used by the GermainUX deployment. Scenarios involving MFA, CAPTCHA, hardware tokens, or interactive identity-provider approval may require a dedicated automation-compatible authentication flow approved by the security team. Grant the synthetic account only the Siebel permissions required by the scenario.

​
Import and configure the scenario

After reviewing the recording:
1

Import the scenario into GermainUX

2

Assign a descriptive name

3

Select the Siebel application and environment

4

Select the Engine or execution location

5

Configure credentials and variables

6

Configure the execution schedule

7

Set an appropriate scenario timeout

8

Define transaction steps and measurements

9

Configure success and failure conditions

10

Configure SLA thresholds and alerts

11

Run the scenario manually

12

Review its steps, screenshots, timings, and errors

13

Enable recurring execution only after validation succeeds

A useful naming convention identifies the application, environment, and workflow:

​
Choose an execution location

Run the scenario from a GermainUX Engine that represents the network path you want to test.
  • Data-center Engine: Core Siebel availability and server-side access
  • Office or regional Engine: User access through a specific corporate network path
  • Cloud Engine: External or internet-facing availability
  • Multiple Engines: Regional performance and network-path differences
The Engine must be able to reach:
  • Siebel CRM
  • The authentication provider
  • Required proxy services
  • Any integrations used by the workflow
  • GermainUX services

​
Validate unattended execution

A scenario that works in the recorder can still fail when executed by an Engine. Before scheduling production monitoring, confirm that:
  • The Engine can reach the Siebel URL.
  • Proxy and firewall rules permit all required connections.
  • The execution host has a compatible browser and driver.
  • Credentials are available to the runtime.
  • The synthetic account is active and not locked.
  • The scenario starts without an existing browser session.
  • Pop-ups, frames, dialogs, downloads, and new windows are handled.
  • Browser resolution does not prevent elements from being located.
  • The expected business outcome is explicitly validated.
  • Data created by the scenario is cleaned up.
  • Failure notifications reach the responsible team.
Run the scenario several times consecutively to identify unstable selectors or timing dependencies.

​
Schedule and alert

Choose a schedule that reflects the importance of the workflow without creating unnecessary load on Siebel. Configure alerts for conditions such as:
  • Login failure
  • Page or view unavailable
  • Required element not found
  • Validation failure
  • Scenario timeout
  • Step duration exceeding its SLA
  • Complete scenario duration exceeding its SLA
  • Consecutive execution failures
Where appropriate, require more than one failed execution before raising an incident to reduce alerts caused by temporary network or timing conditions. However, do not suppress immediate alerts for critical availability checks without assessing the operational risk. Avoid scheduling multiple high-impact scenarios to run simultaneously with the same account or against the same Siebel component.

​
Production-safety checklist

Before enabling recurring production execution:
  • Use a dedicated, least-privilege account.
  • Use clearly identifiable synthetic test records.
  • Avoid modifying real customer or operational data.
  • Prevent the bot from sending real emails or notifications.
  • Prevent the bot from submitting real orders, payments, or irreversible transactions.
  • Define cleanup for all records created by the scenario.
  • Limit execution frequency.
  • Validate logout and session cleanup.
  • Confirm that the account will not be forced through interactive MFA.
  • Configure account-expiration and password-rotation ownership.
  • Define alert recipients and escalation procedures.
  • Record the scenario’s business owner and technical owner.

​
Maintenance

Review synthetic scenarios after:
  • A Siebel release or patch
  • A browser or browser-driver update
  • A change to authentication
  • A modification to a view, applet, field, or button
  • A workflow or integration change
  • A test-data change
  • Repeated intermittent failures
  • A synthetic account password or permission change
Track scenario maintenance as part of the Siebel release process.

​
Troubleshooting

​
The extension does not record actions

Verify that:
  • The extension is installed and enabled.
  • The browser is supported.
  • The extension has access to the Siebel domain.
  • Enterprise browser policies do not block it.
  • The Siebel page was reloaded after installation.
  • The interaction occurs in an accessible browser context.
  • Pop-up windows or frames are included in the recording scope.

​
The scenario fails during replay

Check:
  • The failing selector
  • Whether the target element is created dynamically
  • Whether a wait condition is missing
  • Whether the expected record exists
  • Whether the synthetic account has the required permissions
  • Whether authentication or session behavior has changed
  • Whether the scenario starts from a known state
  • Whether a pop-up, dialog, or frame requires explicit handling

​
The scenario works locally but fails on the Engine

Compare:
  • Browser and driver versions
  • Screen resolution and browser settings
  • Network and proxy access
  • DNS resolution
  • TLS certificates
  • Authentication behavior
  • Credential availability
  • Locale and time-zone settings
  • Test data
  • Siebel environment URL
  • Extensions or policies installed in the local browser

​
The scenario generates intermittent alerts

Replace fixed delays with condition-based waits and verify that selectors remain stable. Also review:
  • Network latency
  • Siebel response-time variation
  • Competing scheduled scenarios
  • Account contention
  • Test-data dependencies
  • Background workflows
  • Environment 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.