Tutorial: Scheduled Data Collection with Lansenger Push

Using “automatically aggregate the previous day’s business data at 8 AM every day and push it to the management group” as the example, this tutorial shows how Scheduled Trigger, HTTP Request, LLM, and Lansenger MCP tools combine in a LanSphere Workflow. It is for developers automating recurring reporting, syncing, and inspection work.

Scenario and Value

Management likes a glance at the previous day’s data before work, but the data lives in business systems, and syncing it by hand has problems:

• Logging in to export, organize, and post to the group every day — repetitive work tying up a dedicated person;
• Easy to miss on holidays and business trips — the rhythm is unstable;
• Everyone formats differently, making group history hard to compare;
• Forwarding raw data directly means too many metrics and poor readability — management cannot catch the point.

Automate this chain with a Workflow: scheduled trigger → fetch data via API → LLM generates a Chinese summary → push to the group as a Lansenger message. Unattended, consistent, and abnormal data gets flagged automatically.

What You Will Build

A Workflow that runs automatically at 08:00 every day: pull the previous day’s data (JSON) from a business-system API, have the LLM aggregate it into a chat-friendly summary in Chinese, then push it to the management group via the Lansenger MCP “Send Group Message” tool. Before work starts, the summary is already waiting quietly in the group.

The chain: Scheduled Trigger → HTTP Request → LLM → MCP (Send Group Message).

Recommended Flow

Preparation

Step 1: Create the App and Configure Environment Variables

1. Click “New Project,” pick the app type “Workflow,” and fill in the name (e.g., “Daily Data Digest Push”).
2. Add two app-level Environment Variables:
   • API_BASE_URL: The business-system API address;
   • API_TOKEN: The API auth credential — mark it as a secret variable (value masked with asterisks).

Note: Always keep credentials and keys in Environment Variables marked as secret — never write them directly into node configurations or prompts, or they could leak when the app is shared.

Step 2: Orchestrate the Canvas

A Workflow is a single-run automation app — triggered, it goes straight to output with no interaction. Add four nodes in order (nodes are added by clicking only; search by fuzzy name match in the node list):

1. Scheduled Trigger

A Start node, serving as the flow’s origin (this scenario needs no “Input” node). In the node configuration, set the schedule rule to 08:00 daily as prompted on the page; the Workflow then triggers automatically on that rule.

Tip: Scheduled-push Workflows use “Scheduled Trigger” as the only origin; to keep manual-run ability, trigger an end-to-end debug manually to verify the chain.

2. HTTP Request

Call the business-system API to pull the previous day’s data:

• Method: GET;
• URL: Reference the Environment Variable API_BASE_URL;
• Headers: Carry auth info as the API requires, with the value referencing the secret variable API_TOKEN;
• Query parameters: Per the API docs (e.g., a date parameter for the previous day).

Referencing Environment Variables for the address and credential — instead of hardcoding — means that when you switch environments (test/production) or credentials, only the variable values change, not the canvas.

3. LLM

Aggregate the JSON returned by the API into a Chinese summary. After picking the model, pass the HTTP Request node’s returned data in as context. Sample prompt:

You are a data-digest assistant. Below is the previous day's data (JSON) returned by the business system:

(Insert the HTTP Request node's output variable here)

Generate a summary in Chinese to push to the management group, with these requirements:
1. Open with one sentence covering the previous day overall (date + core metrics).
2. List the key metrics in bullet points with period-over-period changes, using Chinese metric names.
3. Clearly abnormal data (missing, zero, or overly volatile) gets flagged "Needs Attention" on its own.
4. Summarize only from the given data — do not speculate about causes, do not add anything the data does not contain.
5. Keep it within 200 Chinese characters, suitable for quick reading in a group chat.

4. MCP Node (Send Group Message)

1. Click to add a tool-type node, pick the “MCP” category, and find the “Send Group Message” tool of the Lansenger MCP Service in the pop-up tool list.
2. Configure the target group’s group ID; the message content references the LLM node’s output via the variable picker.

To keep each pushed digest in the run records, connect an “Output” node at the end referencing the LLM node’s output — a Workflow returns its result at the end through the “Output” node.

Node Configuration Quick Reference

Step 3: End-to-End Debug

1. Click “Debug” to run one end-to-end debug, pushing the whole chain through manually.
2. Check node by node:
   • HTTP Request node: confirm the expected JSON data came back;
   • LLM node: confirm the digest meets the prompt requirements with no fabricated content;
   • MCP node: confirm the management group received the message in a readable format.
3. Each node’s input, output, and errors are visible in the debug details; past runs are in “Debug History.”

Troubleshooting common problems:

Step 4: Save and Go Live

1. Click “Save” to save the Workflow. The pre-publish Checklist automatically checks configuration completeness and logic — fill any gaps as prompted.
2. After saving, the Scheduled Trigger node fires automatically on the set rule; the exact enable/disable method follows in-app prompts. To adjust the push rhythm, modify the Scheduled Trigger node’s rule and save again.
3. After 08:00 the next day, open the app details page → “Conversation Logs” tab and confirm there is a run record with a normal status — a Workflow log contains status, start time, elapsed time, total Tokens, input/output, and each node’s intermediate data.

Tip: In the first days after going live, cross-check the group messages against actual business-system data for a few days running — confirm the API semantics, the “previous day” data range, and the digest content all match expectations before letting it run unattended long-term.

Acceptance Checklist

• Every workday after 08:00, the management group receives the digest on time;
• Metrics and values in the digest match the business system’s previous-day data — no fabrication;
• Data anomalies are flagged “Needs Attention” in the digest, helping management locate issues fast;
• Each day’s run record in Conversation Logs has a normal status — no consecutive failures;
• Credentials exist only as secret variables — no plain text on the canvas or in messages.

Ideas for Extension

• Alert routing: Add a “Conditional Branch” node after the LLM node — when the digest contains “Needs Attention,” switch to the “Send Private Message” tool to alert the owner individually;
• Multi-group batch push: Use an “Array Operations” node to send to multiple group IDs in batch;
• External-system triggering: Swap the Start node for “Webhook Callback,” letting the business system call the callback URL when data is ready;
• Keep the raw data: Write the API-returned JSON into the output too, so the digest’s basis is traceable in the logs.