Weaver E10 eBuilder Data Management

Problem It Solves

In Weaver E10 eBuilder, form data operations often require mapping business names to system identifiers such as appTag, formTag, objId, and optionId. Calling APIs directly can lead to inaccurate cross-environment lookup, failed writes for person/department browser fields, and mismatched request structures between custom APIs and OpenAPI.

How It Works

The skill follows a stable workflow for eBuilder data tasks:

• Tag resolution: query appId by appTag, then query objId by formTag, avoiding replacement of objId with formId.
• Metadata reading: load field definitions, options, and mainTable/detailN detail mappings by objId.
• Browser field parsing: resolve person, department, branch, or related browser names into writable optionId or content.
• Data operations: route to published custom APIs or OpenAPI for create, update, delete, detail, pagination, and total count queries.
• Button lookup: query available button actions by objId, dataId, tags, and viewType.

Write operations confirm target, fields, and quantity before execution; delete operations display the data ID/condition and require explicit confirmation.

Boundaries

It is useful for engineers who need stable eBuilder form data access, configuration migration checks, or browser-field resolution. It does not modify tags, use SQL, cross-tenant queries, or undocumented fallback APIs; on 401/403, the workflow returns to session handling instead of bypassing permissions client-side.