📝 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.
|
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
-
Open the target Siebel environment.
-
Start a new recording in the RPA Bot Recorder.
-
Perform the workflow exactly as a user would.
-
Pause for pages and controls to become ready before interacting.
-
Add validations for the expected outcome.
-
Sign out when logout is part of the scenario.
-
Stop the recording.
-
Review the generated Selenium steps.
-
Remove unnecessary actions.
-
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:
-
Login
-
Open Service Requests
-
Search for customer
-
Create Service Request
-
Save
-
Validate result
-
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:
-
Import it into GermainUX.
-
Enter a descriptive name.
-
Select the Siebel application and environment.
-
Select the execution Engine.
-
Configure credentials and variables.
-
Configure the browser and runtime.
-
Set the timeout.
-
Configure transaction steps.
-
Configure success and failure conditions.
-
Run the scenario manually.
-
Review screenshots, steps, timings, and errors.
-
Enable recurring execution only after validation succeeds.
A useful name identifies the application, environment, and workflow:
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.
-
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
📚 Related Documentation
-
Other Analytics Features
-
Other Automation Features
ℹ️ Get Help
The Germain Team can help you set this up. Contact GermainUX Support.
Component: Engine, JS Profiler, Mobile App, RPA Bot Recorder, RUM JS
Feature Availability: 2014.1 or later