@viu/emporix-sdk 3.3.1 → 3.4.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,60 @@
1
1
  # @viu/emporix-sdk
2
2
 
3
+ ## 3.4.1
4
+
5
+ ### Patch Changes
6
+
7
+ - [#325](https://github.com/viuteam/emporix-sdk/pull/325) [`10dc05f`](https://github.com/viuteam/emporix-sdk/commit/10dc05fb1faef990d45ff94615dfe745852165f9) Thanks [@viu-release-bot](https://github.com/apps/viu-release-bot)! - chore(sdk): sync generated types with upstream Emporix API specs
8
+
9
+ Updated services: schema
10
+
11
+ ## 3.4.0
12
+
13
+ ### Minor Changes
14
+
15
+ - [#320](https://github.com/viuteam/emporix-sdk/pull/320) [`5ec1c0b`](https://github.com/viuteam/emporix-sdk/commit/5ec1c0b1876679d381a48a43b8571309224d7c3a) Thanks [@amnael1](https://github.com/amnael1)! - feat(sdk): add import deleteSchedule and document the new run fields
16
+
17
+ Wraps the one operation Emporix added to the Import Service on 2026-09-01
18
+ ([api-references#509](https://github.com/emporix/api-references/pull/509)) and
19
+ documents the three request/response fields that came with it.
20
+ - `client.imports.deleteSchedule(configId)` — remove a configuration's schedule
21
+ so it runs only when triggered. **Idempotent, and deliberately not gated on
22
+ the configuration existing**: removing a schedule that is not there resolves
23
+ just the same, and unlike `setSchedule` the configuration need not still be
24
+ around. That asymmetry is the point — a schedule left behind by a deleted
25
+ configuration is precisely what needs removing. Resolves to `void` (`204`).
26
+
27
+ The other additions needed no new code, because this package's facade types
28
+ alias the generated ones — but they did need documenting, since none of them is
29
+ discoverable from a type:
30
+ - `triggerRun` accepts `sampleSize` (dry-run only, 1–100, default 25) and the
31
+ run comes back with `dryRunSample`: the mapped records the import _would_ have
32
+ written, so a mapping can be previewed without one. Absent on a normal run.
33
+ - `triggerRun` accepts `origin`, free text naming _what_ asked for the run, and
34
+ the run echoes it. `trigger` only records `MANUAL` or `SCHEDULED`, so without
35
+ `origin` a dashboard click and an integration scenario are indistinguishable
36
+ in the history. **Over 40 characters, or containing control characters, is
37
+ rejected rather than shortened** — a truncated label in an audit trail is
38
+ worse than a refused request.
39
+ - `setSchedule` now documents `400` and `404`. The `400` names the six-field
40
+ cron trap explicitly: the familiar five-field `"0 * * * *"` is not «hourly»,
41
+ it is invalid — and the service used to store it and then silently never fire
42
+ it. The SDK already required six fields, so this is now stated where the call
43
+ is made rather than only on the type.
44
+
45
+ `ImportRun`'s and `ImportRunInput`'s JSDoc were stale by one release and now
46
+ name every field, including the `duplicateKeys` / `unresolvedParents` source-feed
47
+ counters — a run can report `SUCCEEDED` with both non-zero, which is exactly why
48
+ they are worth reading.
49
+
50
+ With this the facade covers all 21 operations of the vendored spec.
51
+
52
+ ### Patch Changes
53
+
54
+ - [#319](https://github.com/viuteam/emporix-sdk/pull/319) [`86d2f64`](https://github.com/viuteam/emporix-sdk/commit/86d2f64843980169ccb9c522f6f50184057c5f64) Thanks [@viu-release-bot](https://github.com/apps/viu-release-bot)! - chore(sdk): sync generated types with upstream Emporix API specs
55
+
56
+ Updated services: import-service
57
+
3
58
  ## 3.3.1
4
59
 
5
60
  ### Patch Changes
package/dist/index.cjs CHANGED
@@ -1242,7 +1242,7 @@ var HttpClient = class {
1242
1242
  };
1243
1243
 
1244
1244
  // package.json
1245
- var version = "3.3.1";
1245
+ var version = "3.4.1";
1246
1246
 
1247
1247
  // src/version.ts
1248
1248
  var SDK_VERSION = version;
@@ -8133,7 +8133,19 @@ var ImportService = class {
8133
8133
  });
8134
8134
  return res ?? null;
8135
8135
  }
8136
- /** Create or replace a configuration's schedule. */
8136
+ /**
8137
+ * Create or replace a configuration's schedule.
8138
+ *
8139
+ * **`cron` is a six-field Spring expression** (`second minute hour
8140
+ * day-of-month month day-of-week`). The familiar five-field `"0 * * * *"` is
8141
+ * not «hourly» here, it is invalid, and the service answers `400` rather than
8142
+ * storing it — which it used to do, leaving a schedule that silently never
8143
+ * fired.
8144
+ *
8145
+ * A `404` means no configuration with that id, so there is nothing to
8146
+ * schedule. Use {@link deleteSchedule} to clear a schedule that outlived its
8147
+ * configuration.
8148
+ */
8137
8149
  async setSchedule(configId, input, auth2 = SERVICE29) {
8138
8150
  return this.ctx.http.request({
8139
8151
  method: "PUT",
@@ -8142,11 +8154,50 @@ var ImportService = class {
8142
8154
  auth: auth2
8143
8155
  });
8144
8156
  }
8157
+ /**
8158
+ * Remove a configuration's schedule. It then runs only when triggered.
8159
+ *
8160
+ * **Idempotent, and deliberately not gated on the configuration existing.**
8161
+ * Removing a schedule that is not there also resolves — and unlike
8162
+ * {@link setSchedule}, this does not require the configuration to exist. That
8163
+ * is the point: a schedule left behind by a deleted configuration is exactly
8164
+ * what needs removing, so refusing those would leave them with no way out.
8165
+ *
8166
+ * The service answers `204`, so this resolves to `void` rather than to the
8167
+ * removed schedule.
8168
+ */
8169
+ async deleteSchedule(configId, auth2 = SERVICE29) {
8170
+ await this.ctx.http.request({
8171
+ method: "DELETE",
8172
+ path: `${this.base()}/configs/${encodeURIComponent(configId)}/schedule`,
8173
+ auth: auth2
8174
+ });
8175
+ }
8145
8176
  /**
8146
8177
  * Trigger a run. `mode` defaults to `DELTA` server-side; `dryRun: true` maps
8147
8178
  * and validates without writing to the target.
8148
8179
  *
8180
+ * A dry run can also hand back what it *would* have written: pass
8181
+ * `sampleSize` (1–100, default 25) and read the run's `dryRunSample`. Set
8182
+ * `origin` to name what asked for the run — `trigger` only distinguishes
8183
+ * `MANUAL` from `SCHEDULED`, so without it a dashboard click and an
8184
+ * integration scenario are indistinguishable in the history. Note the service
8185
+ * **rejects** an `origin` over 40 characters instead of shortening it.
8186
+ *
8149
8187
  * Not retried on a 5xx: a POST that timed out may already have queued a run.
8188
+ *
8189
+ * @example
8190
+ * ```ts
8191
+ * // Preview the mapping without writing anything.
8192
+ * const run = await client.imports.triggerRun(configId, {
8193
+ * dryRun: true,
8194
+ * sampleSize: 5,
8195
+ * origin: "Dashboard",
8196
+ * });
8197
+ * for (const row of run.dryRunSample ?? []) {
8198
+ * console.log(row.stream, row.targetType, row.key, row.fields);
8199
+ * }
8200
+ * ```
8150
8201
  */
8151
8202
  async triggerRun(configId, input = {}, auth2 = SERVICE29) {
8152
8203
  return this.ctx.http.request({