Managing Transactions in Salesforce: Why Only One Can Be in Working Status

When working with transactions in Salesforce, especially in custom implementations or integrations involving bots or external systems, it's important to understand a key constraint:

At any given time, only one transaction can be in "Working" status.

This design ensures data integrity and prevents conflicts during concurrent updates. However, it also means that if you attempt to initiate a new transaction while another is still active, Salesforce will block the operation until the previous one is resolved.

How to Handle This Situation

If you find yourself unable to proceed with a new transaction, follow these steps:

1. Identify Active Transactions
   Navigate to the transaction records and look for any entries marked as "Working."

2. Click into Each Active Transaction
   Open each transaction individually to review its status and details.

3. Cancel and Discard Changes
   Use the Cancel Transaction and Discard Changes options to terminate the active transaction. This will release the lock and allow you to proceed with a new one.

4. Retry Your New Transaction
   Once all previous transactions are cleared, you can initiate your new transaction without issues.

Why This Matters

Failing to cancel previous transactions can lead to:

• Errors in automation flows
• Incomplete data updates
• Conflicts in record locking
• Frustration for users and bots alike

By maintaining a clean transaction state, you ensure smoother operations and better system performance.

🔧 How to Open a .nupkg File by Renaming It to .zip (And What to Do If It Doesn’t Work)

If you've ever worked with NuGet packages, you've likely come across files with the .nupkg extension. These are essentially ZIP archives that contain compiled code, metadata, and other resources used in .NET projects. But what if you want to peek inside?

✅ The Quick Tip

You can rename a .nupkg file to .zip and open it like any regular archive. For example:

MyPackage.nupkg → MyPackage.zip

Then, just double-click to explore its contents.

---

🛠️ What to Do If Renaming Doesn’t Work

Sometimes, simply renaming the file doesn’t seem to do the trick. Here are a few things to check:

1. Make Sure File Extensions Are Visible

Windows hides known file extensions by default. This can lead to mistakes like renaming MyPackage.nupkg to MyPackage.zip.nupkg.

Fix it:

• Open File Explorer
• Go to the View tab
• Check File name extensions

2. Use a Zip Tool Directly

Instead of renaming, right-click the .nupkg file and choose:

• Open with → 7-Zip
• Open with → WinRAR
• Or extract it using the Windows built-in zip extractor

🚀 Boosting API Testing with Pre-request and Post-response Scripts in Postman

As I’ve been working on API development and testing, I recently explored how to use Pre-request and Post-response scripts in Postman to automate and streamline my workflow. Here’s what I learned and how you can apply it too!

---

🔧 Pre-request Script: Dynamic Timestamping

I needed to send a request with a timestamp that was exactly 5 hours before the current time. Here’s the script I used:

let now = new Date();
let hour = 60 * 60 * 1000;
let multiplyer = 5;

let time_iso = new Date(now.getTime() - multiplyer * hour);
pm.environment.set("time_iso", time_iso.toISOString());

✅ This script calculates the time offset and stores it in an environment variable time_iso, which I then used in the request body like this:

{
  "timestamp": "{{time_iso}}"
}

---

🔐 Authorization Setup

To authenticate the request, I used a Bearer Token in the Authorization tab:

• Type: Bearer Token
• Token: {{auth_token}} (stored in environment variables)

Alternatively, you can add it manually in the Headers tab:

Key: Authorization
Value: Bearer {{auth_token}}

---

🧪 Post-response Script: Status Check and Token Extraction

After the request, I wanted to validate the response and extract a token for future use. Here’s the script I used:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

let responseData = pm.response.json();

if (responseData.token) {
    pm.environment.set("auth_token", responseData.token);
    console.log("Token saved to environment:", responseData.token);
} else {
    console.warn("Token not found in response");
}

✅ This script checks if the response was successful and saves the token to an environment variable for reuse.

---

💡 Final Thoughts

Using these scripts has made my API testing more dynamic and efficient. I can now automate timestamp generation, handle authentication seamlessly, and extract data from responses without manual effort.

If you're working with APIs in Postman, I highly recommend exploring these scripting features—they’re simple to implement and incredibly powerful!

Oracle Forms “Failed to validate certificate” in UiPath RPA apps — why it happens and how to fix it

UiPath RPA workflow launches an Oracle Forms application (Java Web Start / Oracle Forms applet) and you intermittently get the pop‑up:

“Application Blocked for Security
Failed to validate certificate.
The application will not be executed.
Name: oracle.forms.engine.Main
Location: https://<server>:<port>”

you’re hitting a certificate revocation check problem in the Java client used by Oracle Forms. The issue appears randomly because Java’s Online Certificate Status Protocol (OCSP) checks can time out or fail intermittently against Oracle’s responders, which leads Java to treat the code-signing or TLS certificate as unvalidated and block execution.

Why this affects UiPath

• UiPath typically automates Oracle Forms via a desktop/browser session that loads the Java plugin or JNLP client.

• The robot inherits the same Java security settings as the user session. When OCSP validation is enabled, sporadic network hiccups or responder issues can fail the revocation check, stopping the Oracle client before your workflow starts.

• Because the error occurs before the UI is fully initialized, retries don’t help; the Java runtime blocks the applet/JNLP outright.

Root cause in plain terms

• Java tries to confirm that the certificate used to sign Oracle Forms code (and/or the site’s TLS certificate) hasn’t been revoked.

• When “OCSP” is selected, Java queries an online OCSP responder. If that responder is slow, unreachable, or returns an unexpected response, Java refuses to run the application.

• The result: intermittent “Failed to validate certificate” even when your certificates are valid.

The reliable fix: switch revocation checks to CRL only
Changing Java’s certificate revocation strategy from OCSP (or OCSP+CRL) to CRL only removes the flaky dependency on Oracle’s OCSP responders while still performing revocation checks via downloadable Certificate Revocation Lists.

What to change
Open the Java Control Panel on the robot and set the following under the Advanced tab, Security section.

1. Check for signed code certificate revocation using:

• Select “Certificate Revocation Lists (CRLs)”

• Do not select OCSP or “Both CRLs and OCSP”

2. Perform TLS certificate revocation checks on:

• Choose “All certificates in the chain of trust” (recommended for completeness)

• “Server certificate only” also works if your environment requires it

• Avoid “Do not check”

3. Check for TLS certificate revocation using:

• Select “Certificate Revocation Lists (CRLs)”

• Do not select OCSP or “Both CRLs and OCSP”

Apply and restart the browser/Oracle Forms client. In unattended robots, restart the robot session or machine so the setting is picked up.

Why CRL works better here

• CRLs are cached and refreshed on schedule, so a transient network glitch doesn’t immediately block execution.

• OCSP requires a live responder call during startup; if that call fails or times out, Java blocks the app. That’s the randomness you see.

Operational considerations for RPA teams

• Standardize the Java security settings on all robots via group policy, configuration management, or golden image.

• Ensure robots have access to CRL distribution points (often HTTP/LDAP URLs embedded in the certs). Allowlist those endpoints if you use egress filtering.

• Monitor certificate expirations and keep Java up to date to avoid unrelated security prompts.

• Document the setting so new robot machines match the same configuration.

FAQ

Does switching to CRL reduce security?

• You still perform revocation checks, just via CRL instead of OCSP. Many enterprises standardize on CRL for determinism and caching. If your security policy mandates OCSP, consider deploying an internal OCSP responder or OCSP stapling; otherwise CRL is a practical, reliable choice.

Why does the error mention oracle.forms.engine.Main?

• That’s the main class of the Oracle Forms client. Java blocks it before launch when it can’t validate certificates.

Why is the error intermittent?

• OCSP lookups depend on remote responders. Latency, packet loss, DNS issues, or responder rate limits can cause sporadic failures.

UiPath workflow tip

• Add an environment validation step at the start of your process that checks a sentinel Forms URL and fails fast with a clear exception if Java security settings are incorrect. This saves robot time and simplifies troubleshooting.

Summary

• Symptom: “Failed to validate certificate” popup when launching Oracle Forms in a UiPath‑automated session.

• Cause: Unreliable OCSP revocation checks in Java for Oracle Forms certificates.

• Fix: In Java Control Panel > Advanced > Security, set revocation checks to CRL only for both signed code and TLS, then restart.