@adobe/acc-js-sdk 1.1.10 → 1.1.11
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/README.md +8 -2170
- package/docs/404.html +11 -0
- package/docs/Gemfile +35 -0
- package/docs/Gemfile.lock +270 -0
- package/docs/_config.yml +55 -0
- package/docs/_data/navigation.yml +119 -0
- package/docs/_includes/navigation.html +33 -0
- package/docs/_layouts/default.html +21 -0
- package/docs/_layouts/home.html +4 -0
- package/docs/_layouts/page.html +5 -0
- package/docs/_layouts/post.html +7 -0
- package/docs/_posts/2022-10-14-welcome.html +149 -0
- package/docs/application.html +366 -0
- package/docs/architecture.html +24 -0
- package/docs/assets/css/styles.css +362 -0
- package/docs/assets/images/adobe-campaign-256.png +0 -0
- package/docs/assets/images/architecture.png +0 -0
- package/docs/assets/images/ref.svg +6 -0
- package/docs/badgerFish.html +14 -0
- package/docs/bestPractices.html +189 -0
- package/docs/blog.html +18 -0
- package/docs/buildAndRun.html +96 -0
- package/docs/caches.html +68 -0
- package/docs/changeLog.html +256 -0
- package/docs/checkList.html +168 -0
- package/docs/concepts.html +130 -0
- package/docs/connecting.html +210 -0
- package/docs/connectionParameters.html +109 -0
- package/docs/contribute.html +54 -0
- package/docs/dataTypes.html +124 -0
- package/docs/differences.html +4 -0
- package/docs/documentation.html +21 -0
- package/docs/domHelper.html +88 -0
- package/docs/dynamicInvoke.html +36 -0
- package/docs/entityAccessor.html +22 -0
- package/docs/errors.html +47 -0
- package/docs/escaping.html +76 -0
- package/docs/favicon.png +0 -0
- package/docs/healthCheck.html +66 -0
- package/docs/httpHeaders.html +78 -0
- package/docs/index.html +64 -0
- package/docs/installation.html +34 -0
- package/docs/license.html +208 -0
- package/docs/messageCenter.html +80 -0
- package/docs/methodLevelRepresentation.html +12 -0
- package/docs/midSourcing.html +19 -0
- package/docs/observability.html +169 -0
- package/docs/passwords.html +27 -0
- package/docs/profiles.html +103 -0
- package/docs/pushDown.html +13 -0
- package/docs/quickstart.html +69 -0
- package/docs/release.html +52 -0
- package/docs/samples.html +82 -0
- package/docs/simpleJson.html +88 -0
- package/docs/soapAPIs.html +234 -0
- package/docs/timeouts.html +23 -0
- package/docs/transport.html +45 -0
- package/docs/troubleshooting.html +17 -0
- package/docs/writeDoc.html +208 -0
- package/docs/xml2json.html +96 -0
- package/docs/xtkCaster.html +67 -0
- package/docs/xtkInterface.html +20 -0
- package/docs/xtkOption.html +54 -0
- package/docs/xtkPackage.html +16 -0
- package/docs/xtkPersist.html +213 -0
- package/docs/xtkQueryDef.html +245 -0
- package/docs/xtkSchema.html +39 -0
- package/docs/xtkSession.html +29 -0
- package/docs/xtkWorkflow.html +28 -0
- package/docs/xtkWrite.html +51 -0
- package/package-lock.json +1 -1
- package/package.json +1 -1
- package/src/campaign.js +1 -1
- package/src/soap.js +6 -6
- package/test/soap.test.js +13 -0
- package/CHANGELOG.md +0 -252
package/docs/caches.html
ADDED
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
layout: page
|
|
3
|
+
title: Caches
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
<p>The following caches are managed by the SDK and active by default. They are in-memory caches.</p>
|
|
8
|
+
|
|
9
|
+
<ul>
|
|
10
|
+
<li>Options cache. Stores typed option values, by option name.</li>
|
|
11
|
+
<li>Entity cache. Caches schemas and other entities</li>
|
|
12
|
+
<li>Method cache. Cahces SOAP method definitions.</li>
|
|
13
|
+
</ul>
|
|
14
|
+
|
|
15
|
+
<p>Caches can be cleared at any time</p>
|
|
16
|
+
<pre class="code">
|
|
17
|
+
client.clearOptionCache();
|
|
18
|
+
client.clearMethodCache();
|
|
19
|
+
client.clearEntityCache();
|
|
20
|
+
</pre>
|
|
21
|
+
|
|
22
|
+
<p>or </p>
|
|
23
|
+
<pre class="code">
|
|
24
|
+
client.clearAllCaches();
|
|
25
|
+
</pre>
|
|
26
|
+
|
|
27
|
+
<p>Caches have a TTL of 5 minutes by default. The TTL can be changed at connection time using connection options <b>entityCacheTTL</b>, <b>methodCacheTTL</b>, and <b>optionCacheTTL</b>.</p>
|
|
28
|
+
|
|
29
|
+
<p>Caches can be de-activated by setting a TTL of -1 which will have the effect of making all cached data always invalid.</p>
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
<h1>Persistent caches</h1>
|
|
34
|
+
<p>In addition to memory caches, it is possible to use persistent caches as well. This was introduced in version 1.0.5 and is active by default as well when using the SDK in a browser. The browser local storage is used (if allowed).</p>
|
|
35
|
+
|
|
36
|
+
<p>Cached data is stored in local storage with keys prefixed with <b>acc.js.sdk.{{version}}.{{server}}.cache.</b> where <b>version</b> is the SDK version and <b>server</b> is the Campaign server name. This means that the cached data is lost when upgrading the SDK.</p>
|
|
37
|
+
|
|
38
|
+
<p>It's possible to disable persistent caches using the <b>noStorage</b> connection option.</p>
|
|
39
|
+
|
|
40
|
+
<p>It is also possible to setup one's own persistent cache, by passing a <b>storage</b> object as a connection option. This object should implement 3 methods: <b>getItem</b>, <b>setItem</b>, and <b>removeItem</b> (synchronous)</p>
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
<h1>Auto-refresh caches</h1>
|
|
44
|
+
|
|
45
|
+
<p>The SDK includes a mechnism to maintain the schemas and options caches up-to-date by polling the Campaign server on a regular basis (10 seconds by default). The server returns the list of entities (schemas or options) which have changed since they were cached, and the client removes them from the cache. When a schema changes, the corresponding methods are also removed from the method cache.</p>
|
|
46
|
+
|
|
47
|
+
<p>This mechanism is not activate by default but can be activated or deactivated by the following functions</p>
|
|
48
|
+
|
|
49
|
+
<pre class="code">
|
|
50
|
+
client.startRefreshCaches(30000); // activate cache auto-refresh mechanism every 30s
|
|
51
|
+
client.stopRefreshCaches(); // de-activate cache auto-refresh
|
|
52
|
+
</pre>
|
|
53
|
+
|
|
54
|
+
<p>This mechanism is based on the <b>xtk:session#GetModifiedEntities</b> SOAP method which is only available in Campaign 8.4 and above only. For other builds of Campaign, the auto-refresh mechanism will not do anything. </p>
|
|
55
|
+
|
|
56
|
+
<p>The following changes are handled:</p>
|
|
57
|
+
<ul>
|
|
58
|
+
<li>If the build number has changed, the whole cache is cleared</li>
|
|
59
|
+
<li>If more than 10 schemas or options have changed, the whole cache is cleared</li>
|
|
60
|
+
<li>if less than 10 schemas or options have changed, only those entities are removed from the cache</li>
|
|
61
|
+
</ul>
|
|
62
|
+
|
|
63
|
+
<p>The refresh mechanism includes the following guardrails</p>
|
|
64
|
+
<ul>
|
|
65
|
+
<li>Both xtk:option and xtk:schema caches are refreshed every n seconds. To avoid issuing two API calls at the same time to the server, the schema cache refresh call is delayed by a few seconds. In the future this delay may change.</li>
|
|
66
|
+
<li>If the xtk:session#GetModifiedEntities API is not available, the auto refresh mechanism will silently stop automatically</li>
|
|
67
|
+
<li>If an error occurs while trying to refresh, a warning will be logged to the JavaScript console but the auto refresh will not be stopped. </li>
|
|
68
|
+
</ul>
|
|
@@ -0,0 +1,256 @@
|
|
|
1
|
+
---
|
|
2
|
+
layout: page
|
|
3
|
+
title: Change Log
|
|
4
|
+
---
|
|
5
|
+
<section class="changelog"><h1>Version 1.1.11</h1>
|
|
6
|
+
<h2>2022/11/09</h2>
|
|
7
|
+
|
|
8
|
+
<li>Correction of a false positive session expiration error. The processing of the session expiration error (code XSV-350008) was incorrect as it was searching for the error code anywhere in an API response body instead of checking for an actual error</li>
|
|
9
|
+
</section>
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
<section class="changelog"><h1>Version 1.1.10</h1>
|
|
13
|
+
<h2>2022/10/13</h2>
|
|
14
|
+
|
|
15
|
+
<li>Added support for <b>primaryKey</b> type
|
|
16
|
+
<li>Added support for the <b>xtk:persist</b> interface
|
|
17
|
+
<li>Added support for schema belongsTo attribute
|
|
18
|
+
</section>
|
|
19
|
+
<section class="changelog"><h1>Version 1.1.9</h1>
|
|
20
|
+
<h2>2022/10/11</h2>
|
|
21
|
+
|
|
22
|
+
<li>Added support for schema visibleIf attribute
|
|
23
|
+
</section>
|
|
24
|
+
<section class="changelog"><h1>Version 1.1.8</h1>
|
|
25
|
+
<h2>2022/10/03</h2>
|
|
26
|
+
|
|
27
|
+
<li>Added translation ids <b>labelLocalizationId</b>, <b>descriptionLocalizationId</b>, <b>labelSingularLocalizationId</b>) for <b>XtkSchema</b>, <b>XtkSchemaNode</b>, <b>XtkEnumerationValue</b> and <b>XtkEnumeration</b>
|
|
28
|
+
</section>
|
|
29
|
+
<section class="changelog"><h1>Version 1.1.7</h1>
|
|
30
|
+
<h2>2022/08/30</h2>
|
|
31
|
+
|
|
32
|
+
<li>New listener interface to be notified of internal events from the SDK. Can be used to integrate with observability frameworks. See the "Observers" section of the README file.
|
|
33
|
+
<li>Experimental file upload feature. Will require server-side changes to work, and is currently limited to be used with browsers only.
|
|
34
|
+
</section>
|
|
35
|
+
<section class="changelog"><h1>Version 1.1.6</h1>
|
|
36
|
+
<h2>2022/08/19</h2>
|
|
37
|
+
|
|
38
|
+
<li>New auto-refresh mechanism to keep schemas and option caches up-to-date. See <b>client.startRefreshCaches</b> and <b>client.stopRefreshCaches</b> functions.
|
|
39
|
+
</section>
|
|
40
|
+
<section class="changelog"><h1>Version 1.1.5</h1>
|
|
41
|
+
<h2>2022/07/07</h2>
|
|
42
|
+
|
|
43
|
+
<li>The SOAP method name was not showing up properly in the Chrome console
|
|
44
|
+
</section>
|
|
45
|
+
<section class="changelog"><h1>Version 1.1.4</h1>
|
|
46
|
+
<h2>2022/07/07</h2>
|
|
47
|
+
|
|
48
|
+
<li>Added <b>application.version</b> which returns the server version in the format major.minor.servicePack (ex: 8.2.10)
|
|
49
|
+
<li>Added the ability to push down parameters to the SOAP and transport layers. See the pushDown section of the readme file.
|
|
50
|
+
<li>The pushDown mechanism can be used to simply overwrite the request timeout, either globally or at the method level
|
|
51
|
+
<li>Publicly export the HttpError class so that custom transports can be written more safely. A failure during transport should return an HttpError object
|
|
52
|
+
<li>By default, the SOAP method name is now added in the URLs for better troubleshooting
|
|
53
|
+
</section>
|
|
54
|
+
<section class="changelog"><h1>Version 1.1.3</h1>
|
|
55
|
+
<h2>2022/05/30</h2>
|
|
56
|
+
|
|
57
|
+
<li>Fix a bug in client.hasPackage which was returning an incorrect result when passed a single parameter (it would always return false). Fixed the corresponding unit test too.
|
|
58
|
+
<li>Fix a bug causing API calls having a input parameter of type "int" to fail. Usually the type is described as "long", but sometimes "int" is used instead, such as, for instance, in the <b>nms:extAccount#UpdateMCSynchWkf</b> method.
|
|
59
|
+
<li>When using XML representations and DOMDocument method parameter type, the SDK expects to be passed an actual DOM document. Now it supports being passed a DOM element too. This is a common case when using the <b>nms:delivery#createFromModel</b> API followed by a <b>xtk:session#Write</b> API call.
|
|
60
|
+
<li>Avoid the error 'Cannot transform entity to xml because no XML root name was given' by using SOAP method parameter name as the default for XML document root when no other root is available
|
|
61
|
+
<li>Document how to set the password of an external account
|
|
62
|
+
<li>By default, SDK will send additional HTTP headers to help troubleshooting and usage tracking
|
|
63
|
+
<li>Add the ability to pass extra HTTP headers to API calls, either globally (to all HTTP headers), or locally, i.e. for a specific method
|
|
64
|
+
<li>Remove .vscode folder from the sources
|
|
65
|
+
<li>Example for xtkBuilder.installPackage API
|
|
66
|
+
<li>For APIs which have parameters of type DOMElement and which are called using XML, support passing either a DOMElement or a DOMDocument
|
|
67
|
+
|
|
68
|
+
</section>
|
|
69
|
+
<section class="changelog"><h1>Version 1.1.2</h1>
|
|
70
|
+
<h2>2022/03/22</h2>
|
|
71
|
+
|
|
72
|
+
<li>Add support for choosing the representation (XML or JSON) at the method level using NLWS.xml or NLWS.json.
|
|
73
|
+
</section>
|
|
74
|
+
<section class="changelog"><h1>Version 1.1.1</h1>
|
|
75
|
+
<h2>2022/03/10</h2>
|
|
76
|
+
|
|
77
|
+
<li>Fixed an issue with encoding: make the default charset encoding to be UTF-8 (https://github.com/adobe/acc-js-sdk/issues/26)
|
|
78
|
+
</section>
|
|
79
|
+
<section class="changelog"><h1>Version 1.1.0</h1>
|
|
80
|
+
<h2>2022/03/05</h2>
|
|
81
|
+
|
|
82
|
+
Changes in the metadata api (<b>application.getSchema</b>) which was not completely implemented. While this API is meant to be largely compatible with the [ACC JS API](https://docs.adobe.com/content/help/en/campaign-classic/technicalresources/api/c-Application.html), it's not always possible to do so because of the asynchronous nature of the SDK. The JS API is executed inside the Campaign application server can will synchronously and transparently fetch schemas as needed. Howerer the SDK runs outside of the Campaign server. It will synchronously and transparently fetch schemas as needed, but this will be done adynchronously.
|
|
83
|
+
|
|
84
|
+
Differences are document in the <b>Application</b> section of the README.
|
|
85
|
+
|
|
86
|
+
<li>Provide array and map access to XtkSchemaKey.fields,
|
|
87
|
+
<li>The order of children of a node has been changed. Beore 1.1.0, it was attributes, then elements. After 1.1.0, it's the order defined in the schema XML
|
|
88
|
+
<li>New application.getEnumeration function to retreive an enumeration
|
|
89
|
+
<li>Removed the XtkSchemaNode.hasChild function
|
|
90
|
+
<li>Support for ref nodes and links: XtkSchemaNode.refTarget(), XtkSchemaNode.linkTarget() functions
|
|
91
|
+
<li>Reviews XtkSchemaNode.findNode() function to support links, refs, ANY type, etc. and is now asynchronous
|
|
92
|
+
<li>The name attribute of enumerations (<b>XtkEnumeration.name</b>) is now the fully qualified name of the enumeration, i.e. is prefixed by the schema id
|
|
93
|
+
</section>
|
|
94
|
+
<section class="changelog"><h1>Version 1.0.9</h1>
|
|
95
|
+
<h2>2022/03/02</h2>
|
|
96
|
+
|
|
97
|
+
<li>Ability to invoke SOAP calls dynamically with parameters computed at invocation time by a delegate function
|
|
98
|
+
<li>Fixed bug in XPath constructor which now supports expanded paths, i.e. xpaths such as <b>[@recipient-id]</b>.
|
|
99
|
+
<li>EntityAccessor: change the heuristic to detect XML types: use "nodeType" and "tagName" functions instead of "insertAdjacentElement" (which was not always working in the context of a React application)
|
|
100
|
+
<li>Add new escaping functions: <b>escapeForLike</b>, <b>expandXPath</b>, <b>unexpandXPath</b>, <b>xtkConstText</b>
|
|
101
|
+
<li>New XtkCaster methods: <b>asDatetime</b> (alias to <b>asTimestamp</b>), <b>isStringType</b>, and <b>isNumericType</b>
|
|
102
|
+
<li>Metadata API (application.getSchema)
|
|
103
|
+
<li>keys have a <b>isInternal</b> internal attribute which was mistakenly using the "string" type. It's now correctly using the boolean type.
|
|
104
|
+
<li>Added missing attributes on the XtkSchema: md5
|
|
105
|
+
<li>Added missing attributes on the XtkSchemaNode objects: dataPolicy, editType folderModel, enumerationImage, size, userEnumeration, hasUserEnumeration, isCollection,
|
|
106
|
+
isAdvanced, isAnyType, isLink, hasEnumeration, hasSQLTable, SQLName, SQLTable, isMappedAsXML, isTemporaryTable, isElementOnly, isDefaultOnDuplicate, isExternalJoin,
|
|
107
|
+
isMemo, isMemoData, isBlob, isCDATA, isNotNull, isRequired, isSQL, PKSequence, revLink, isCalculated, expr, isAutoIncrement, isAutoPK, isAutoUUID, isAutoStg, packageStatusString, and packageStatus
|
|
108
|
+
<li>Attribute type defaults to string if not set
|
|
109
|
+
<li>Removed userDescription attribut from schema nodes (only available at the schema level)
|
|
110
|
+
<li>Changed the toString function to use 4 spaces instead of 3 for indentation and display node label and internal name
|
|
111
|
+
<li>When label or description is missing from schema nodes or from enumerations, they default to the name value
|
|
112
|
+
<li>application.getSchema now uses a in-memory cache
|
|
113
|
+
|
|
114
|
+
For breaking changes see the [migration guide](MIGRATION.md)
|
|
115
|
+
|
|
116
|
+
</section>
|
|
117
|
+
<section class="changelog"><h1>Version 1.0.7</h1>
|
|
118
|
+
<h2>2022/01/24</h2>
|
|
119
|
+
<li>Added a hook <b>refreshClient</b> on connection parameters. This is a callback called when an authentication token expires. It can be used to implement reconnection logic
|
|
120
|
+
<li>New attributes on the schema API (application.getSchema)
|
|
121
|
+
<li>The <b>enum</b> attribute of a schema node returns the corresponding enum attribute, i.e. the enumeration name
|
|
122
|
+
<li>The <b>target</b> attribute of a schema node (of type link) returns the target (schema id) of the link
|
|
123
|
+
<li>The <b>integrity</b> attribute of a schema node (of type link) returns the link integrity ("define", "own", etc.)
|
|
124
|
+
<li>Added a github workflow for code analysis (CodeQL) to detect more potential issues before release
|
|
125
|
+
<li>Upgrade dependencies to fix some vulnerabilities
|
|
126
|
+
<li>Add new conversion functions in XtkCaster to support for int, timespan, uuid, html and blob
|
|
127
|
+
</section>
|
|
128
|
+
<section class="changelog"><h1>Version 1.0.6</h1>
|
|
129
|
+
<h2>2021/11/03</h2>
|
|
130
|
+
<li>New ofBearerToken authentication for IMS access token
|
|
131
|
+
<li>Fix a small issue in the compile script which did not create the dist folder if it was missing
|
|
132
|
+
<li>Fix an intermittent bug when running the SDK in the browser and when using local storage cache. The schema cache and method cache
|
|
133
|
+
should contain XML representation of Campaign schemas and methods. Before it is put in local storage, data needs to be serialized
|
|
134
|
+
as text. This was only working of JavaScript objects, but DOM elements were not being serialied causing various errors when
|
|
135
|
+
using the cache later
|
|
136
|
+
</section>
|
|
137
|
+
<section class="changelog"><h1>Version 1.0.5</h1>
|
|
138
|
+
<h2>2021/10/09</h2>
|
|
139
|
+
<li>Fix an issue in the logon() function which was not always returning a promise. Some authentication methods such as SessionToken we returning synchronously. Made it so that logon always returns a promise. This should not be a breaking change as logon does not actually return a value
|
|
140
|
+
<li>Refactor caches (Options cache, Schemas cache, and Methods cache) to use a generic cache class
|
|
141
|
+
<li>Make sure options parameter of ConnectionParameters constructor is not modified
|
|
142
|
+
<li>Added a persistent cache for schemas, methods, and options using the browser localStorage by default
|
|
143
|
+
<li>Make sure X-Security-Token header is hidden as well as session token cookies
|
|
144
|
+
<li>Added jshint configuration and fixed warnings reported by jshint
|
|
145
|
+
<li>Fixed vulnerability in ansi-regex; upgrade jest-junit to version 13 to fix
|
|
146
|
+
<li>Small jsdoc improvements
|
|
147
|
+
</section>
|
|
148
|
+
<section class="changelog"><h1>Version 1.0.4</h1>
|
|
149
|
+
<h2>2021/10/07</h2>
|
|
150
|
+
<li>Fix a bug which caused XML text and cdata elements to be skipped during SimpleJson transformation
|
|
151
|
+
<li>Make sure passwords are not logged (replace with "***") when activating traces
|
|
152
|
+
</section>
|
|
153
|
+
<section class="changelog"><h1>Version 1.0.3</h1>
|
|
154
|
+
<h2>2021/10/06</h2>
|
|
155
|
+
<li>Added the <b>sdk.ip()</b> function to retreive the ouptbound IP to be whitelisted to access Campaign
|
|
156
|
+
<li>New <b>ofSecurityToken</b> authentication method for the client-side SDK, which can be used to log on with a security token only. The session token will be passed automatically by the browser.
|
|
157
|
+
</section>
|
|
158
|
+
<section class="changelog"><h1>Version 1.0.2</h1>
|
|
159
|
+
<h2>2021/09/17</h2>
|
|
160
|
+
<li>Dummy version to fix NPM build. Need to have the version in both package.json and a commit message to be "Release x.y.z" in master
|
|
161
|
+
</section>
|
|
162
|
+
<section class="changelog"><h1>Version 1.0.1</h1>
|
|
163
|
+
<h2>2021/09/16</h2>
|
|
164
|
+
<li>Dummy version to fix NPM build
|
|
165
|
+
</section>
|
|
166
|
+
<section class="changelog"><h1>Version 1.0.0</h1>
|
|
167
|
+
<h2>2021/09/16</h2>
|
|
168
|
+
<li>Support for a simpler flavor of JSON (see SimpleJson vs. BadgerFish) which is now the default
|
|
169
|
+
<li>New <b>EntityAccessor</b> object to access entity properties regardless of their representation
|
|
170
|
+
<li>Finalize the implementation to support int64
|
|
171
|
+
<li>Add 100% coverage for all tests
|
|
172
|
+
<li>Make some members of the Client object private to clarify what is the public API
|
|
173
|
+
<li>Fixed bug in JSON serialization for XML elments having an attribute named "length" (see <b>isArray</b> utility)
|
|
174
|
+
<li>New <b>application</b> object to mimic the public SDK (can be accessed via <b>client.application</b>)
|
|
175
|
+
<li>New schema API (<b>application.getSchema</b>) to easily navigate schemas
|
|
176
|
+
<li>New Campaign enumeration constants (<b>campaign.js</b>) for better readability of code using numerical enumeration values
|
|
177
|
+
<li>BadgerFish objects now have a <b>__representation = "BadgerFish"</b> attribute to easily distinguish between BadgerFish & SimpleJson
|
|
178
|
+
<li>Logon will fail if server returns a payload which does not contain a <b>userInfo</b> object
|
|
179
|
+
<li>New <b>setOption</b> function which allows to set (and cache) an option value
|
|
180
|
+
<li>Deprecated the <b>getSecretKeyCipher</b> function which may fail on instances where Vault is setup. Use <b>ConnectionParameters.ofExternalAccount</b> instead
|
|
181
|
+
<li><b>getEntityIfMoreRecent</b> now takes an additional parameter which allows to specify and force a representation (xml, json...)
|
|
182
|
+
<li>New helper function <b>DomUtil.isArray</b> to test if a JavaScript object is an array
|
|
183
|
+
<li>New <b>EntityAccessor</b> object which allows to get attributes and child elements from xml or json objects, regardless of their representation
|
|
184
|
+
<li>New <b>escapeXtk</b> function to escape litteral values in Xtk expression. Can be used as a function or as a tagged template litteral
|
|
185
|
+
<li>New function <b>XtkCaster._variantStorageAttribute</b> which returns the name of a schema attribute used to store variant value types. The name of the attribute depends on the type: stringValue, longValue, etc.
|
|
186
|
+
<li>Support for non static method that mutate the object on which they apply. For instance, the <b>xtk:queryDef#SelectAll</b>
|
|
187
|
+
<li>Added samples in the samples/ folder
|
|
188
|
+
<li>Support of logon with session token only with sdk.ConnectionParameters.ofSessionToken
|
|
189
|
+
<li>Error management. Return a proper CampaignException upon failure with attributes that can be used to retreive error details (both http and soap)
|
|
190
|
+
<li>Message Center API and examples
|
|
191
|
+
<li>Added support for anonymous authentication via the "ofAnonymousUser" credentials function
|
|
192
|
+
<li>Implement SDK functions for /r/test, /nl/jsp/ping.jsp, nl/jsp/mcPing.jsp (health check functions)
|
|
193
|
+
<li>All HTTP request now add a user agent string identifying the SDK and it's version
|
|
194
|
+
<li>CampaignException has been improved to report errors on both SOAP and HTTP requests. It's now defined in <b>campaign.js</b>
|
|
195
|
+
<li>Added full jsdoc documentation of the SDK (run with <b>npm run jsdoc</b>). Result is saved in the <b>doc/jsdoc</b> folder
|
|
196
|
+
<li>Use "strict" mode
|
|
197
|
+
<li>Use E6 classes instead of prototype based inheritance
|
|
198
|
+
<li>Using <b>axios</b> as the default protocol instead of <b>request-promise-native</b> which is deprecated
|
|
199
|
+
<li>Added the notion of observer that can be called on any SOAP or HTTP request
|
|
200
|
+
<li>SOAP calls now have an "internal" flag, which indicates if the SOAP calls comes from the framework itself (for example, the framework will load schemas) or from a client app
|
|
201
|
+
<li>All session and security tokens are removed from logs
|
|
202
|
+
<li>Moved to DomUtil.isArray helper function to a new Utils package (internal)
|
|
203
|
+
<li>Fixed many tests which were not executed corresctly (assertion was not executed, leading to think the test was successful)
|
|
204
|
+
<li>Fixed CVE-2021-23343 in dependencies
|
|
205
|
+
|
|
206
|
+
_Breaking changes in 1.0.0_
|
|
207
|
+
<li>The default representation is now <b>SimpleJson</b> instead of <b>BadgerFish</b>
|
|
208
|
+
<li>Changes in the <b>sdk.init</b>, <b>Client</b> constructor, and <b>logon</b> functions. Now using <b>ConnectionParameters</b> and <b>Credentials</b> objects to configure a Campaign connection
|
|
209
|
+
<li>Client object members are now private: access to representation, etc. attributes is not allowed anymore except for <b>NLWS</b>, <b>XtkCaster</b>, and <b>DomUtil</b>
|
|
210
|
+
<li>Access to the <b>sessionInfo</b> object after <b>logon</b> can be done via the new <b>getSessionInfo</b> call
|
|
211
|
+
<li>Options cache internal strucutre change: option values in the cache are now object litterals containing the option value, type, and raw value (which may not be casted to the expected type yet)
|
|
212
|
+
<li>Connecting to mid-sourcing (or other Campaign instances which are defined by an external account) is now done with the <b>ConnectionParameters.ofExternalAccount</b> function. As a consequence, <b>getSecretKeyCipher</b> is now private and deprecated
|
|
213
|
+
<li>CampaignException object signature changed (but was not previously exposed)
|
|
214
|
+
<li>The client-side bundle is now generated in the <b>dist/bundle.js</b> file instead of <b>bundle.js</b>
|
|
215
|
+
<li>The main global object for the client SDK is now <b>document.accSDK</b> and not <b>accSDK</b>
|
|
216
|
+
<li>The client.traceSOAPCalls() function is now named client.traceAPICalls because it traces both SOAP and HTTP calls
|
|
217
|
+
|
|
218
|
+
---
|
|
219
|
+
</section>
|
|
220
|
+
<section class="changelog"><h1>Version 0.1.24</h1>
|
|
221
|
+
<h2>2021/09/16</h2>
|
|
222
|
+
<li>Fix potential security vulnerabilities in the dependencies
|
|
223
|
+
</section>
|
|
224
|
+
<section class="changelog"><h1>Version 0.1.23</h1>
|
|
225
|
+
<h2>2021/07/27</h2>
|
|
226
|
+
<li>Support for int64 type (represented as a string to avoid rounding errors)
|
|
227
|
+
<li>Fix issue with the SoapAction header for interface methods. When calling a method which is defined on an interface (for instance xtk:persist), the SoapAction
|
|
228
|
+
header must use the interface id and not the schema id. For instance, when one calls the xtk:session Write method, one should call NLWS.xtkSession.Write, but
|
|
229
|
+
the SoapAction header must be "xtk:persist#Write" and not "xtk:session#Write" for the call to complete successfully. In older SDK versions, one had to call
|
|
230
|
+
NLWS.xtkPersist.Write which would only work if the xtk:persist interface schema was cached before. As there's no xtk:schema entity for the interfaces, the only
|
|
231
|
+
way to cache such an interface is to have previously called a method on xtk:session. This call will indirectly cache the xtk:session schema and its interfaces,
|
|
232
|
+
hence xtk:persist. From SDK 0.1.23 on, while the previous (incorrect) syntax NLWS.xtkPersist.Write still works, it's recommended to use NLWS.xtkSession.Write
|
|
233
|
+
<li>Upgrade 3rd parties (browserslist, hosted-git-info, lodash, ws) to fix vulnerabilities
|
|
234
|
+
</section>
|
|
235
|
+
<section class="changelog"><h1>Version 0.1.22</h1>
|
|
236
|
+
<h2>2021/02/23</h2>
|
|
237
|
+
<li>Update node-notifier library (used by jest) to version 8.0.1 to fix a possible injection
|
|
238
|
+
</section>
|
|
239
|
+
<section class="changelog"> <h1>0.1.20</h1>
|
|
240
|
+
<h2>Add client.hasPackage function to test if </h2> package is installed or an instance or not (https://github.com/adobe/acc-js-sdk/issues/5)
|
|
241
|
+
</section>
|
|
242
|
+
<section class="changelog"> <h1>0.1.3</h1>
|
|
243
|
+
<h2>Bug fixe</h2>
|
|
244
|
+
<li>Query returning empty result should return null when getIfExists operation, should fail when using get operation, and should return an empty array with select operation (https://github.com/adobe/acc-js-sdk/issues/3)
|
|
245
|
+
</section>
|
|
246
|
+
<section class="changelog"> <h1>0.1.2</h1>
|
|
247
|
+
<h2><li>Use github action to automatically publ</h2>sh to npm when one pushes a commit with the message "Release 1.2.3"
|
|
248
|
+
</section>
|
|
249
|
+
<section class="changelog"> <h1>0.1.1</h1>
|
|
250
|
+
<h2>Bug fixe</h2>
|
|
251
|
+
<li>Query in select mode should always return an array, even if result is empty or one one row (https://github.com/adobe/acc-js-sdk/issues/1)
|
|
252
|
+
|
|
253
|
+
</section>
|
|
254
|
+
<section class="changelog"> <h1>0.1.0</h1>
|
|
255
|
+
<h2>Initial versio</h2>
|
|
256
|
+
|
|
@@ -0,0 +1,168 @@
|
|
|
1
|
+
---
|
|
2
|
+
layout: page
|
|
3
|
+
title: Commit Checklist
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<p>In summary, the following tasks <b>must</b> be performed before submitting a pull request</p>
|
|
7
|
+
|
|
8
|
+
<ul>
|
|
9
|
+
<li>Check that tests run with 100% coverage</li>
|
|
10
|
+
<li>Check and resolve any security issues</li>
|
|
11
|
+
<li>Check if there are any code warnings</li>
|
|
12
|
+
<li>Check that JavaScript documentation builds and is complete</li>
|
|
13
|
+
<li>Check that your new features or fixed are documented and appear in the changelog</li>
|
|
14
|
+
<li>Check that the client-side library builds and work</li>
|
|
15
|
+
<li>Review your own code and fix any thing that looks hack, fix all typos, etc., document all public functions, etc.</li>
|
|
16
|
+
</ul>
|
|
17
|
+
|
|
18
|
+
<p></p>
|
|
19
|
+
<pre class="code">
|
|
20
|
+
npm i
|
|
21
|
+
npm run unit-tests
|
|
22
|
+
npm audit
|
|
23
|
+
node_modules/jshint/bin/jshint src/
|
|
24
|
+
npm run jsdoc
|
|
25
|
+
open ./docs/jsdoc/index.html
|
|
26
|
+
node ./compile.js
|
|
27
|
+
</pre>
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
<h1>Write and run tests</h1>
|
|
32
|
+
|
|
33
|
+
<p>
|
|
34
|
+
The JS SDK has 100% coverage and should stay so. Each PR <b>must</b> include a series of unit test which test that
|
|
35
|
+
the feature works, but also test all the error cases and edge cases. In general it's better to write more tests
|
|
36
|
+
than few.
|
|
37
|
+
</p>
|
|
38
|
+
<p>
|
|
39
|
+
Tests should be fast. We will not accept tests which wait for timeouts for example. Each test should not run for
|
|
40
|
+
more than a few ms.
|
|
41
|
+
</p>
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
<pre class="code">
|
|
45
|
+
npm run unit-tests
|
|
46
|
+
</pre>
|
|
47
|
+
|
|
48
|
+
<p>
|
|
49
|
+
The result should look like this
|
|
50
|
+
</p>
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
<pre class="code">
|
|
54
|
+
PASS test/soap.test.js
|
|
55
|
+
PASS test/xtkPersist.test.js
|
|
56
|
+
PASS test/domUtil.test.js
|
|
57
|
+
PASS test/caches.test.js
|
|
58
|
+
PASS test/testUtil.test.js
|
|
59
|
+
PASS test/entityAccessor.test.js
|
|
60
|
+
PASS test/client.hasPackage.test.js
|
|
61
|
+
PASS test/xtkProxy.test.js
|
|
62
|
+
PASS test/credentials.test.js
|
|
63
|
+
PASS test/index.test.js
|
|
64
|
+
PASS test/crypto.test.js
|
|
65
|
+
PASS test/xtkCaster.test.js
|
|
66
|
+
PASS test/escape.test.js
|
|
67
|
+
PASS test/transport.test.js
|
|
68
|
+
PASS test/util.test.js
|
|
69
|
+
PASS test/web.bundler.test.js
|
|
70
|
+
PASS test/error.test.js
|
|
71
|
+
--------------------|---------|----------|---------|---------|-------------------
|
|
72
|
+
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
|
|
73
|
+
--------------------|---------|----------|---------|---------|-------------------
|
|
74
|
+
All files | 100 | 100 | 98.8 | 100 |
|
|
75
|
+
src | 100 | 100 | 98.8 | 100 |
|
|
76
|
+
application.js | 100 | 100 | 100 | 100 |
|
|
77
|
+
cache.js | 100 | 100 | 100 | 100 |
|
|
78
|
+
cacheRefresher.js | 100 | 100 | 100 | 100 |
|
|
79
|
+
client.js | 100 | 100 | 100 | 100 |
|
|
80
|
+
crypto.js | 100 | 100 | 100 | 100 |
|
|
81
|
+
domUtil.js | 100 | 100 | 97.29 | 100 |
|
|
82
|
+
entityAccessor.js | 100 | 100 | 85.71 | 100 |
|
|
83
|
+
errors.js | 100 | 100 | 100 | 100 |
|
|
84
|
+
index.js | 100 | 100 | 100 | 100 |
|
|
85
|
+
methodCache.js | 100 | 100 | 100 | 100 |
|
|
86
|
+
optionCache.js | 100 | 100 | 100 | 100 |
|
|
87
|
+
soap.js | 100 | 100 | 100 | 100 |
|
|
88
|
+
testUtil.js | 100 | 100 | 100 | 100 |
|
|
89
|
+
transport.js | 100 | 100 | 100 | 100 |
|
|
90
|
+
util.js | 100 | 100 | 93.33 | 100 |
|
|
91
|
+
xtkCaster.js | 100 | 100 | 95.65 | 100 |
|
|
92
|
+
xtkEntityCache.js | 100 | 100 | 100 | 100 |
|
|
93
|
+
src/web | 100 | 100 | 100 | 100 |
|
|
94
|
+
bundler.js | 100 | 100 | 100 | 100 |
|
|
95
|
+
--------------------|---------|----------|---------|---------|-------------------
|
|
96
|
+
|
|
97
|
+
Test Suites: 21 passed, 21 total
|
|
98
|
+
Tests: 1773 passed, 1773 total
|
|
99
|
+
Snapshots: 0 total
|
|
100
|
+
Time: 11.654 s
|
|
101
|
+
</pre>
|
|
102
|
+
|
|
103
|
+
<p>Run tests</p>
|
|
104
|
+
<pre class="code">
|
|
105
|
+
npm run unit-tests
|
|
106
|
+
</pre>
|
|
107
|
+
|
|
108
|
+
|
|
109
|
+
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+
<h1>Check for security issues</h1>
|
|
113
|
+
|
|
114
|
+
<p>
|
|
115
|
+
Run <b>npm audit</b> to check for security issues. If any is found, make sure to fix it before you pull request your PR.
|
|
116
|
+
</p>
|
|
117
|
+
|
|
118
|
+
<pre class="code">
|
|
119
|
+
npm audit
|
|
120
|
+
</pre>
|
|
121
|
+
|
|
122
|
+
<p>
|
|
123
|
+
It should not return any errors or warnings
|
|
124
|
+
</p>
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
|
|
128
|
+
|
|
129
|
+
<h1>Run the linter</h1>
|
|
130
|
+
|
|
131
|
+
<p></p>
|
|
132
|
+
|
|
133
|
+
<pre class="code">
|
|
134
|
+
node_modules/jshint/bin/jshint src/
|
|
135
|
+
</pre>
|
|
136
|
+
|
|
137
|
+
<p>
|
|
138
|
+
It should not return any errors or warnings
|
|
139
|
+
</p>
|
|
140
|
+
|
|
141
|
+
|
|
142
|
+
|
|
143
|
+
|
|
144
|
+
<h1>Generate and run the JS doc</h1>
|
|
145
|
+
|
|
146
|
+
<p></p>
|
|
147
|
+
|
|
148
|
+
<pre class="code">
|
|
149
|
+
npm run jsdoc
|
|
150
|
+
</pre>
|
|
151
|
+
|
|
152
|
+
<p>
|
|
153
|
+
It should not return any errors or warnings. You should then open the generated documentation and check it
|
|
154
|
+
</p>
|
|
155
|
+
|
|
156
|
+
<pre class="code">
|
|
157
|
+
open ./docs/jsdoc/index.html
|
|
158
|
+
</pre>
|
|
159
|
+
|
|
160
|
+
|
|
161
|
+
|
|
162
|
+
<h1>Document your changes</h1>
|
|
163
|
+
|
|
164
|
+
<p></p>
|
|
165
|
+
|
|
166
|
+
<p class="ref">Follow <a href="{{ site.baseurl }}/writeDoc.html">this link</a> to understand how to document your changes</p>
|
|
167
|
+
|
|
168
|
+
<p>You'll also have to change the <a href="{{ site.baseurl }}/changeLog.html">Changelog file</a></p>
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
---
|
|
2
|
+
layout: page
|
|
3
|
+
title: Concepts
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<h1>The Campaign Object model</h1>
|
|
7
|
+
<p>
|
|
8
|
+
Campaign has schemas to describe every piece of data. For instance recipients have a schema : nms:recipient. Even Schemas
|
|
9
|
+
have their own schema (xtk:schema). A Campaign schema is more than just a description of the data, the available properties
|
|
10
|
+
of an entity and their types. Campaign schemas are really similar to classes in an object model: they describe the data
|
|
11
|
+
of course, but they also contain <b>methods</b> which will be made available automatically as SOAP APIs. Schemas also
|
|
12
|
+
support an inheritance mechanism, including the notion of <b>interface</b>. An interface is simply a descrption of one or
|
|
13
|
+
several methods. Schemas inheriting the interface will inherit their methods.
|
|
14
|
+
</p>
|
|
15
|
+
|
|
16
|
+
<h1>Campaign SOAP APIs</h1>
|
|
17
|
+
|
|
18
|
+
<p>
|
|
19
|
+
Campaign SOAP APIs are not REST APIs. Not only, we're using SOAP and XML, but Campaign also uses a very different model for APIs.
|
|
20
|
+
In fact we use a object oriented model, i.e. APIs in Campaign are closer to remote methods invocation than REST APIs are. For
|
|
21
|
+
instance, imagine what a REST API call to retreive a profile would look like. You'll probably issue a GET operation on the profile
|
|
22
|
+
resource with a more or less sophisticated mechanism to filter the selected profile based on query parameters.
|
|
23
|
+
</p>
|
|
24
|
+
<p>
|
|
25
|
+
In Campaign, you'll execute a query. You are going to use the <b>ExecuteQuery</b> method of the <b>xtk:queryDef</b> schema. This
|
|
26
|
+
API actually directly matches the method VExecuteQuery of the XtkQueryDef class of the C++ code.
|
|
27
|
+
</p>
|
|
28
|
+
|
|
29
|
+
<pre class="code">
|
|
30
|
+
<srcSchema <span class="emphasis">namespace="xtk"</span> <span class="emphasis">name="queryDef"</span> implements="xtk:persist">
|
|
31
|
+
<element name="queryDef" pkgStatus="never">...</element>
|
|
32
|
+
<methods async="true">
|
|
33
|
+
<method <span class="emphasis">name="ExecuteQuery"</span> const="true">
|
|
34
|
+
<parameters>
|
|
35
|
+
<param desc="Output XML document" name="output" type="DOMDocument" inout="out"/>
|
|
36
|
+
</parameters>
|
|
37
|
+
</method>
|
|
38
|
+
...
|
|
39
|
+
</methods>
|
|
40
|
+
</srcSchema>
|
|
41
|
+
</pre>
|
|
42
|
+
<p class="caption">This is the <b>xtk:queryDef</b> source schema, which defines the <b>ExecuteQuery</b> method</p>
|
|
43
|
+
|
|
44
|
+
<p>
|
|
45
|
+
To name APIs, we use the convention <b>{schemaId}#{methodName}</b>. For instance, the <b>ExecuteQuery</b> method of the
|
|
46
|
+
<b>xtk:queryDef</b> schema is named by its <b>URN</b>: <b>xtk:queryDef#ExecuteQuery</b>. The <b>URN</b> is an important concept
|
|
47
|
+
and is passed to every SOAP call through the <b>SOAPAction</b> HTTP header.
|
|
48
|
+
</p>
|
|
49
|
+
<p>
|
|
50
|
+
Sometimes, methods which are inherited from an interface. For example the Write method is defined in the xtk:persist interface which is
|
|
51
|
+
implemented by the xtk:session schema. For such methods, the URN is <b>xkt:persist|xtk:session#Write</b>, where we have both the interface
|
|
52
|
+
id and the schema id separated by a pipe character.
|
|
53
|
+
</p>
|
|
54
|
+
|
|
55
|
+
<pre class="code">
|
|
56
|
+
<srcSchema namespace="xtk" name="queryDef"</span> <span class="emphasis">implements="xtk:persist"</span>>
|
|
57
|
+
...
|
|
58
|
+
</srcSchema>
|
|
59
|
+
</pre>
|
|
60
|
+
<p class="caption">Thee <b>xtk:queryDef</b> inherits the <b>xtk:persist</b> interface</p>
|
|
61
|
+
|
|
62
|
+
<p>
|
|
63
|
+
Regarding schema inheritance, it is possible to define custom methods in derived schemas. For example, a customer may extend
|
|
64
|
+
the nms:recipient schema with an extension schema named cus:recipient, and may declare one or more custom methods in this extension
|
|
65
|
+
schema. Such methods will of course be exposed as SOAP APIs, but they are available on the base schema only, i.e. on nms:recipient
|
|
66
|
+
and not on cus:recipipent. The reason for this is that Campaign actually merges all the schemas and their extensions (which we all
|
|
67
|
+
call source schemas, by the way) into the actual schema which takes the name of the base source schema. As a consequence, the
|
|
68
|
+
SDK actually always deal with schemas, and not source schemas, although it is also possible to handle source schemas by calling
|
|
69
|
+
the appropriate APIs.
|
|
70
|
+
</p>
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
<h1>Representations</h1>
|
|
75
|
+
|
|
76
|
+
<p>
|
|
77
|
+
The SDK works with the underlying notion of <b>representation</b>. Internally, Campaign uses XML to represent all entities.
|
|
78
|
+
Using XML is fine, but nowadays, people find it complicated and verbose and prefer to use JSON.
|
|
79
|
+
</p>
|
|
80
|
+
<p>
|
|
81
|
+
The SDK is able to handle both XML and JSON representation for Campagin objects. It defaults to JSON, which means you pass JSON
|
|
82
|
+
objects to the SDK and it returns JSON objects, and takes care of the JSON <=> XML conversion automatically. The SDK is not limited
|
|
83
|
+
to JSON, but can use XML instead (DOM API) if you change the representation.
|
|
84
|
+
</p>
|
|
85
|
+
|
|
86
|
+
<p>3 type of representation are handled by the SDK</p>
|
|
87
|
+
<ul>
|
|
88
|
+
<li>The <b>SimpleJson</b> representation, which is the default is used to deal with JSON instead of XML</li>
|
|
89
|
+
<li>The <b>xml></b> representation is used to deal with XML. In fact it does not transform anything, this is the native language of Campaign</li>
|
|
90
|
+
<li>The <b>BadgerFish</b> representation, which is an alternative variant of JSON and is deprecated. It's only there for backwards compatibility</li>
|
|
91
|
+
</ul>
|
|
92
|
+
|
|
93
|
+
<p></p>
|
|
94
|
+
<p class="ref">To understand the challenges and pitfalls of XML to JSON conversion, follow <a href="{{ site.baseurl }}/xml2json.html">this link</a></p>
|
|
95
|
+
<p class="ref">To know more about the SimpleJson representation, follow <a href="{{ site.baseurl }}/simpleJson.html">this link</a></p>
|
|
96
|
+
<p class="ref">To better understand how Campaign deals with XML and use helpers to simplify your code, follow <a href="{{ site.baseurl }}/domHelper.html">this link</a></p>
|
|
97
|
+
<p class="ref">To know more about the BadgerFishs representation, follow <a href="{{ site.baseurl }}/badgerFish.html">this link</a></p>
|
|
98
|
+
|
|
99
|
+
|
|
100
|
+
<h1>Asynchronous API</h1>
|
|
101
|
+
|
|
102
|
+
<p>
|
|
103
|
+
The JS SDK provides an asynchronous API, which means most of the functions return promises.
|
|
104
|
+
In particular, many functions in the <a href="{{ site.baseurl }}/application.html">Application API</a> return promises.
|
|
105
|
+
</p>
|
|
106
|
+
<p>
|
|
107
|
+
This is an important difference between the SDK and Campaign. The reason is that the JavaScript which runs inside
|
|
108
|
+
Campaign is running server side and is synchronous. The SDK however, is running outside of Campaign and needs to
|
|
109
|
+
be able to wait for the result of API calls.
|
|
110
|
+
</p>
|
|
111
|
+
|
|
112
|
+
|
|
113
|
+
<p class="ref">To understand the differences between the JS SDK and Campaign JS, follow <a href="{{ site.baseurl }}/differences.html">this link</a></p>
|
|
114
|
+
|
|
115
|
+
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
<srcSchema name="recipient" namespace="nms" label="Recipients">
|
|
119
|
+
<element img="nms:recipient.png" name="recipient" autopk="true">
|
|
120
|
+
</element>
|
|
121
|
+
<methods>
|
|
122
|
+
<method name="RegisterGroup" static="true">
|
|
123
|
+
<parameters>
|
|
124
|
+
<param name="groupList" type="DOMElement" desc="Lists"/>
|
|
125
|
+
<param name="recipientList" type="DOMElement" desc="Recipient list"/>
|
|
126
|
+
<param name="register" type="boolean" desc="Subscribe/Unsubscribe recipients"/>
|
|
127
|
+
</parameters>
|
|
128
|
+
</method>
|
|
129
|
+
</methods>
|
|
130
|
+
</srcSchema>
|