#Tableau APIs & Embedding13 personnes en discutent

Hey Tony, 

The core fix here is architectural: your Apex REST endpoint should do almost nothing synchronously. Right now, if your handler is doing lead validation, dedup logic, or DML inline before returning a response, that's what's blowing past the 504 threshold under load, real business logic execution easily drifts past 2-3 seconds, which the gateway treats as a dropped connection. 

Recommended pattern: 

1. Inbound Apex REST method only: validates the payload/signature, publishes a Platform Event with the raw data, and returns HTTP 200 immediately. Nothing else happens in that thread. 

2. A separate Platform Event trigger picks up the event asynchronously, does your actual business validation, then enqueues a Queueable job (implementing Queueable, Database.AllowsCallouts if you need outbound calls) to do the real processing/DML. 

3. Cap callouts below Salesforce's 100-per-transaction limit, chain overflow records to a new Queueable automatically rather than dropping them. 

4. If Apex's async queue itself hits a capacity rejection under heavy concurrent load, catch that exception and fall back to a Scheduled job (e.g., retry in ~20 seconds) so nothing gets silently dropped. 

This decouples network response time from your actual processing time entirely, so gateway timeouts stop being a factor regardless of how complex the downstream logic is. Your observation that direct REST calls resolve under 150ms but webhooks spike under concurrency confirms it's specifically the synchronous processing inside the handler causing the bottleneck, not the API layer itself. 

Also worth adding: idempotency (dedupe on a unique payload ID) since Platform Events and async retries can occasionally redeliver, and Named Credentials for any outbound calls so secrets stay out of code.

Hi Raju, 

 Recently we have built a Tableau Dashboard Extension that adds a chat panel right inside the dashboard — so instead of eyeballing charts, users can just ask questions in plain English ("what drove the drop in Q2 expenses?", "compare loan fees to expense spend") and get grounded, numeric answers. 

How it works: 

• One lightweight local/hosted backend serves multiple dashboards at once — the model automatically figures out which dataset(s) a question is about, and can even blend two datasets in one answer.
• Every answer is computed by the LLM writing read-only SQL against a real snapshot database (using Tableau's own Hyper engine) — not hallucinated numbers, not a live query against the workbook. This keeps answers fast, accurate, and safe even on 10M+ row extracts.
• Each dataset ships with auto-generated reference docs (a description + data glossary) so the model understands field meanings, grain, and caveats before answering.
• An admin flow can onboard a brand-new Tableau Cloud workbook automatically: pull it via the REST API, extract the embedded data, and have the LLM draft the descriptive docs itself.
• Row-level-security workbooks are auto-detected and blocked from onboarding unless explicitly overridden, so a shared snapshot never leaks restricted rows.

Please upvote this response if this will be helpful to you. 

Regards 

Rajneesh

Tableau can work well for this type of HR analytics workflow, but the best approach depends on how frequently the gratuity data needs to be refreshed. For scheduled reporting across departments or employee groups, Tableau Prep can help clean and structure API responses before bringing the data into dashboards. A Web Data Connector may be better when you need a more direct connection to an external service. 

For UAE payroll reporting, having a reliable calculation source is important because gratuity values depend on factors including salary details and completed service periods. A resource like:

, can help validate the end-of-service benefit calculations before those figures are visualized in Tableau. 

A practical setup could involve pulling employee-level gratuity data through an API, storing the processed results in a database or spreadsheet layer, and then allowing Tableau to focus on trends, department comparisons, and liability forecasting. This also makes it easier for HR teams to audit the numbers before sharing reports internally.

Hi @Umesh Chorge

dealing with WebEditing and credentials can be a bit unstable. I've seen a lot of instances over the years were credentials for some mysterious reasons were not committed or using old ones or using credentials from another tenants while the Analysts were working daily on multiples tenants.  

This is one example: 

As you seem to work with embedded data source directly in the workbook, as Diego said in his earlier post, use published data sources. To keep your datasource stable and modify your workbook content irrelevant of Athena connections even in WebEdit. 

And ideally you modify your published data sources using Tableau Desktop if you can.

Hi @Mukesh Mathur

Yes, it's possible, but Tableau doesn't typically execute SAP T-Codes directly. A common approach is to expose the underlying data through