@adobe/acc-js-sdk 1.1.10 → 1.1.12

package/docs/xtkCaster.html

@@ -0,0 +1,67 @@
+---
+layout: page
+title: Type conversion (XtkCaster)
+---
+
+<p>
+  Campaign <a href="{{ site.baseurl }}/dataTypes.html">data types</a> have some specifities. For instance number can
+  never be null, and Campaign uses 0 instead. In addition, <a href="{{ site.baseurl }}/xml2json.html">XML to JSON</a> is not always accurate
+  and the conversion may return strings instead of booleans, objects instead of arrays, etc.
+</p>
+
+<p>
+  The <b>XtkCaster</b> class is here to help and can be used to coerce an value to any type. For instance
+  if <i>you know</i> that a value is a boolean, but are not sure if it was actually returned as a boolean,
+  you can use the <b>XtkCaster</b> to ensure this. The <b>XtkCaster.asBoolean(value)</b> will ensure this.
+</p>
+
+<p>You get a static <b>XtkCaster</b> object like this</p>
+<pre class="code">
+const XtkCaster = sdk.XtkCaster;
+</pre>
+
+<p>or directly from the client for convenience</p>
+<pre class="code">
+const XtkCaster = client.XtkCaster;
+</pre>
+
+<p>To convert a Campaign value into a given type, use one of the following.</p>
+<pre class="code">
+stringValue = XtkCaster.asString(anyValue);
+booleanValue = XtkCaster.asBoolean(anyValue);
+byteValue = XtkCaster.asByte(anyValue);
+shortValue = XtkCaster.asShort(anyValue);
+int32Value = XtkCaster.asLong(anyValue);
+numberValue = XtkCaster.asNumber(anyValue);
+timestampValue = XtkCaster.asTimestamp(anyValue);
+dateValue = XtkCaster.asDate(anyValue);
+</pre>
+
+<p>More dynamic conversions can be achieved using the <b>as</b> function. See the types table above for details.</p>
+
+<pre class="code">
+stringValue = XtkCaster.as(anyValue, 6);
+</pre>
+
+<p>In addition, the following helpers are available</p>
+<ul>
+<li><b>XtkCaster.isTimeType</b> to test if a data type is a date, time or timestamp</li>
+<li><b>XtkCaster.isStringType</b> to test if a data type is a string type (string, memo, etc.)</li>
+<li><b>XtkCaster.isNumericType</b> to test if a data type is a numeric type</li>
+</ul>
+
+
+
+<h1>Arrays</h1>
+
+<p>
+  Arrays can be tricky to handle when converted from XML: an empty array will be converted to a null or undefined
+  values, an array containing exactly one element may be converted into the element itself. The <b>XtkCaster.asArray</b>
+  will ensure that it's parameter will be converted to an array, possibly empty.
+</p>
+
+<pre class="code">
+expect(XtkCaster.asArray(null)).toStrictEqual(<span class="emphasis">[]</span>);
+expect(XtkCaster.asArray("Hello")).toStrictEqual(<span class="emphasis">["Hello"]</span>);
+expect(XtkCaster.asArray(["Hello", "World""])).toStrictEqual(<span class="emphasis">["Hello", "World""]</span>);
+</pre>

package/docs/xtkInterface.html

@@ -0,0 +1,20 @@
+---
+layout: page
+title: XTK interfaces
+---
+
+<p>Campaign schemas are following an object model. An interface is a set of methods. For instance, the "xtk:persist" interface, defined in the "xtk:session" schema, has a NewInstance method.
+Schemas can implement interface, which means they inherit and implement the methods of the interface. Such methods are internally called using a particular SOAP call URN, which is formed of the interface name, followed by a pipe character, followed by the implementation schema id. For instance "xtk:persist|nms:delivery" is used to indicate that we're calling a method of the xtk:persist on a nms:delivery object which implements the xtk:persist interface.</p>
+
+<p>The version 1.1.9 of the SDK properly implement this type of calls and will deal with this complexity for you. For instance, you can simply call the NewInstance method as follows:</p>
+
+<pre class="code">
+// Create a proxy delivery object
+const delivery = client.NLWS.nmsDelivery.create({ label: "Hello" });
+
+// Call the xtk:persist|nms:delivery#NewInstance method to retreive the default
+// values of a delivery object before actually saving the delivery
+await delivery.newInstance();
+</pre>
+
+<p>There are 2 common interfaces: <a href="{{ site.baseurl }}/xtkPersist.html">xtk:persist</a> and <a href="">xtk:jobInterface</a> which are documented below.</p>

package/docs/xtkOption.html

@@ -0,0 +1,54 @@
+---
+layout: page
+title: Managing options
+---
+
+
+<h1>Reading options</h1>
+
+<p>A convenience function is provided, which returns a typed option value.</p>
+<pre class="code">
+var value = await client.getOption("XtkDatabaseId");
+</pre>
+
+Options are cached because they are often used. It's possible to force the reload of an option:
+<pre class="code">
+var value = await client.getOption("XtkDatabaseId", false);
+</pre>
+
+<p>It's also possible to call the API directly.</p>
+<p>Use the <b>xtk:session:GetOption</b> method to return an option value and it's type. This call will not use the option cache for returning the option value, but will still cache the result.</p>
+
+<pre class="code">
+const optionValueAndType = await NLWS.xtkSession.getOption("XtkDatabaseId");
+console.log("Marketing datbaseId: " + optionValueAndType);
+
+Marketing datbaseId: u7F00010100B52BDE,6
+</pre>
+
+<p>If the option does not exist, it will return [ "", 0 ]</p>
+
+<pre class="code">
+var datbaseId = await client.getOption("XtkDatabaseId");
+console.log(datbaseId);
+</pre>
+
+<p>The <a href="{{ site.baseurl }}/caches.html">cache</a> can be cleared.</p>
+<pre class="code">
+client.clearOptionCache();
+</pre>
+
+
+<h1>Setting options</h1>
+
+<p>It's also possible to set options with the <b>setOption</b> function.</p>
+<ul>
+<li>It will create the option if necessary</li>
+<li>If the option already exists, it will use the existing value to infer the data type of the option</li>
+</ul>
+
+<pre class="code">
+await client.setOption("MyOption", "My value");
+</pre>
+
+<p>This is really a convenience function. You can always force an option type by using a writer on the xtk:option table, and using getOption to read back and cache the result.</p>

package/docs/xtkPackage.html

@@ -0,0 +1,16 @@
+---
+layout: page
+title: Packages
+---
+
+<p>Test if a package is installed. Expects to be connected to an instance. Available since version 0.1.20</p>
+
+<pre class="code">
+var hasAmp = client.hasPackage("nms:amp");
+</pre>
+
+<p>or</p>
+
+<pre class="code">
+var hasAmp = client.hasPackage("nms", "amp");
+</pre>

package/docs/xtkPersist.html

@@ -0,0 +1,213 @@
+---
+layout: page
+title: CRUD operations (xkt:persist)
+---
+<p>There are several possibillities to create objects in Campaign.</p>
+
+
+
+<h1>Create from scratch</h1>
+
+<p>This first method is to create an object from scratch. It's a multi-step operation which contains the following steps</p>
+
+<ul>
+<li>Create an object with the "create" function. This function takes an optional parameter with the attributes you know you're going to set</li>
+<li>Call the <b>xtk:persist#NewInstance</b> API which will generate a unique id, and complete your object with default values (such as default folder, etc.) depending on your role</li>
+<li>Optionally set more attributes to override any defaults</li>
+<li>Call <b>save()</b> or <b>xtk:session#Write</b> to create the object in the database </li>
+</ul>
+
+<p></p>
+<pre class="code">
+    const delivery = client.NLWS.nmsDelivery.create({ 
+      label: "Test #1", 
+      messageType: "0" 
+    });
+    await delivery.newInstance();
+    delivery.$desc = "My description";
+    await client.NLWS.xtkSession.write(delivery); // or await delivery.save();
+</pre>
+
+<p>You'll notice that this method does not return anything. You may have expected this method to return the created object or some id of this object,
+  but Campaign does not. Campaign works the other way round. You first get call NewInstance which will give the id before the object is actually saved
+  in the database.</p>
+
+<pre class="code">
+    const delivery = client.NLWS.nmsDelivery.create({ 
+      label: "Test #1", 
+      messageType: "0" 
+    });
+    await delivery.newInstance();
+    // delivery.entity.id is the future id of the object in the database
+</pre>
+
+<p>If you need to modify the object again after it's been created, you can use <b>xtk:session#Write</b> or save again, but you must tell Campaign to perform an update operation instead of an insert, or the call will probably fail or create a duplicate in the database.
+  Make sure to read the section about the <b>xtk:session#Write</b> method below to understand how exactly objects are updated
+</p>
+
+<pre class="code">
+    delivery._operation = "update";
+    delivery.$desc = "My updated description";
+    await delivery.save();
+</pre>
+
+<p>Finally, to delete the object, use <b>xtk:session#Write</b> or save again, this time passing it the "_operation=delete" attribute</p>
+
+<pre class="code">
+    delivery._operation = "delete";
+    await delivery.save();
+</pre>
+
+<h1>Create by duplicating an existing object</h1>
+
+<p>Sometimes, you do not want to create objects from scratch. Instead you can copy an existing object. Campaign has a sophisticated mechanism to duplicate object and ensures that only the relevant attributes are actually set. For instance, when you dupliate a delivery which is finished, you probably want the new delivery to be in the edition state rather than in the finished state. Schema attributes having the "defOnDuplicate" property will be reset to their defaults in the duplicated object.</p>
+
+<p>Just like the <b>NewInstance</b> API, the <b>xtk:persist#Duplicate</b> will automatically set the primary key for you. And again, it is a multi-step process.</p>
+
+<ul>
+<li>Create an object with the "create" function. This time, do no pass any parameters</li>
+<li>Call the duplicate method, passing it the primary key of the entity you want to duplicate</li>
+<li>Optionally set more attributes to override any defaults</li>
+<li>Call save() or xtk:session#Write to create the object in the database </li>
+</ul>
+
+<p></p>
+
+<pre class="code">
+    const operator = client.NLWS.xtkOperator.create();
+    await operator.duplicate("xtk:operator|1610");
+    operator.name = "Alex";
+    await operator.save();
+</pre>
+
+<p>The primary key format is described in the data types section of this document.</p>
+
+
+<h1>Updating entities</h1>
+
+<p>Entities can be updated using the <b>xtk:session#Write</b> API. This API is very flexible and also can be used to create or delete entities or to modify multiple entites at once.</p>
+
+<p>More examples of the <b>xtk:session#Write</b> API <a href="{{ site.baseurl }}/xtkPersist.html">here</a>.</p>
+
+<p>This method takes an unique argument which is a patch to apply. A patch has the same structure as an entity, but only contains the attributes or elements that need to be modified, created, or deleted. In addition to the value, the patch can also use the _operation property to indicate if a particular set of data needs to be inserted, updated or deleted.
+  The patch object also must have the <b>xtkschema</b> property set to the schema id of the entity to modify.
+</p>
+
+<p>For instance, one can update the email of a recipient with the following code which clearly shows the xtkschema property, the id and _operation properties to indicate that it is an update and which entity to update, and finally, the email attribute which is the only modified attribute.</p>
+
+<pre class="code">
+    client.NLWS.xtkSession.write({ xtkschema: "nms:recipient", 
+                                   id: "1234", _operation:"update", 
+                                   email: "amorin@adobe.com"
+                                });
+</pre>
+
+<p>It's of course possible to pass the whole entity to an update, but this is strongly discouraged as it can have unwanted side effects in complex scenario when passed nested documents with linked objects. It's also less performant, and may overwrite data. 
+  Passing a patch (sometimes called a diff) containing only the actually modified attributes is the best practice. It also has the benefit to allow some sort of concurrent modifications as each update will onlly update the attributes actually changed.</p>
+
+
+<h1>Setting foreign keys</h1>
+
+<p>It's pretty common to have to set foreign keys. For instance one want to set the folder in which a recipient is stored. The first possibility is to set the folder-id attribute directly. It's also the most efficient, but it assumes you know the foreign key in the first place.</p>
+
+<pre class="code">
+    client.NLWS.xtkSession.write({ xtkschema: "nms:recipient", 
+                                    xtkschema:"nms:recipient", 
+                                    id: 2020, _operation:"update", 
+                                    "folder-id": 6040
+                                });
+</pre>
+
+<p>If you do not know the primary key of the folder but know its name, you can use the following syntax. It works for all collections, where items can be identified with their keys (as defined in the schemas).</p>
+
+<pre class="code">
+    client.NLWS.xtkSession.write({ xtkschema: "nms:recipient", 
+                                    xtkschema:"nms:recipient", 
+                                    id: 1990, _operation:"update", 
+                                    folder: {
+                                        _operation: "none",
+                                        name: "test"
+                                    }
+                                });
+</pre>
+
+<p class="info">Note the <b>operation="none"</b> attribute on the folder element which tells Campaign that we should not actually update the folder object itself, but to set the recipient folder instead. If you omit the _operation: "none" property, Campaign will modify both the recipient, but also the folder. It is useful in some cases, but does not make sense in this scenario.</p>
+
+
+<h1>Identifying entities</h1>
+
+<p>We've had a glimpse of it but the xtk:session#Write API has several strategies to identify entities, both the top level entity but also linked entities as we've seen with the recipient folder example above.</p>
+
+<ul>
+<li>If the entity is an "autopk" entity, i.e. has autopk=true set defined in its schema, then it will have an internal primary key using the @id attribute. If the corresponding id is set in the patch document, it will be used to identify the object. </li>
+<li>Otherwise, it will use the entity keys, as defined in the schema.</li>
+</ul>
+
+<p>For instance, folders are an autopk entity and have the id attribute. They also have 2 keys: name and fullName. All 3 can be used as identifiers to update a folder label as the 3 examples below show</p>
+
+
+<pre class="code">
+    // Update folder by id
+    await client.NLWS.xtkSession.write({ 
+        xtkschema: "xtk:folder", 
+          _operation: "update", id: 1234,
+          label: "Hello World",
+        });
+    });
+
+    // Update folder by name
+    await client.NLWS.xtkSession.write({ 
+        xtkschema: "xtk:folder", 
+          _operation: "update", name: "test",
+          label: "Hello World",
+        });
+    });
+
+    // Update folder by full name
+    // This is just for example, do not use this method as the folder full name is the concatenation
+    // of the folder label and it's parent folders labels. Changing the label will create an
+    // inconsistency between the folder full name and its label. You can update other attributes though.
+    await client.NLWS.xtkSession.write({ 
+        xtkschema: "xtk:folder", 
+          _operation: "update", fullName: "/Profiles and Targets/Recipients/Hello/",
+          label: "Hello World",
+        });
+    });
+</pre>
+
+
+<h1>Deleting data</h1>
+
+<p>The <b>xtkSession#write</b> API can also be used to delete data using the "_operation=delete" attribute. For a delete operation, the patch should contain the xtkschema attribute, the _operation=delete attribute and an identifier of the entity.</p>
+
+<p>For insance, a folder can be delete with</p>
+
+<pre class="code">
+    await client.NLWS.xtkSession.write({ 
+        xtkschema: "xtk:folder", 
+          _operation: "delete", name: "test",
+        });
+    });
+</pre>
+
+<p>Owned entities which are also autopk will also be deleted</p>
+
+
+<h1>Setting ids</h1>
+
+<p>In the previous examples we showed how to create or update object and let Campaign generate the ids. In some cases, you'll want to explictiely set the ids upfront. To ensure uniqueness of the ids, Campaign provides an API to "reserve" ids in advane that you can use afterwards: xtk:session#GetNewIdsEx.</p>
+
+<p>In this example, we're getting an id and creating a recipient. The id can be re-used in subsequent calls as a foreign key</p>
+
+<pre class="code">
+    const idList = XtkCaster.asArray(await client.NLWS.xtkSession.GetNewIdsEx(1, "XtkNewId"));
+    await client.NLWS.xtkSession.write({ xtkschema:"nms:recipient", id: idList[0], email: 'amorin@adobe.com' });
+</pre>
+
+<p>Note that</p>
+<ul>
+  <li>Calling GetNewIdsEx for individual ids is not efficient. It's usually better to reserve a large range of ids and insert multiple rows using those ids</li>
+  <li>Inserting data in unitary fashion with API calls is not efficient. Use data management workflows for large imports</li>
+  <li>Make sure that the NLWS.xtkSession.GetNewIdsEx returns an array by using XtkCaster.asArray(...)</li>
+</ul>
+

package/docs/xtkQueryDef.html

@@ -0,0 +1,245 @@
+---
+layout: page
+title: Query API
+---
+
+<p>
+    The <b>xtk:queryDef</b> schema contains generic methods to query the database and retrieve any kind of entites, both
+    out-of-the-box and custom.
+</p>
+
+<p class="warning">This API is not meant for high concurrency. It is fit for a reasonble usage without the limits of the capacity you purchased.</p>
+
+<p>List all accounts</p>
+
+<pre class="code">
+const queryDef = {
+    schema: "nms:extAccount",
+    operation: "select",
+    select: {
+        node: [
+            { expr: "@id" },
+            { expr: "@name" }
+        ]
+    }
+};
+const query = NLWS.xtkQueryDef.create(queryDef);
+
+console.log(query);
+const extAccounts = await query.executeQuery();
+console.log(JSON.stringify(extAccounts));
+</pre>
+
+<p>Get a single record</p>
+<pre class="code">
+const queryDef = {
+    schema: "nms:extAccount",
+    operation: "get",
+    select: {
+        node: [
+            { expr: "@id" },
+            { expr: "@name" },
+            { expr: "@label" },
+            { expr: "@type" },
+            { expr: "@account" },
+            { expr: "@password" },
+            { expr: "@server" },
+            { expr: "@provider" },
+        ]
+    },
+    where: {
+        condition: [
+            { expr: "@name='ffda'" }
+        ]
+    }
+}
+const query = NLWS.xtkQueryDef.create(queryDef);
+const extAccount = await query.executeQuery();
+</pre>
+
+
+
+<h1>Query operations</h1>
+
+<p>
+    The <b>operation</b> attribute of a query indicates what kind of query operation to perform amongst the following. It is defined
+    in the <b>xtk:queryDef:operation</b> enumeration.
+</p>
+<ul>
+    <li><b>get</b> is used to query one and exactly one record. If the record does not exist, it is considered to be an error. If this happens, the SDK will actually throw a JavaScript error</li>
+    <li><b>getIfExist</b> is used to query one record which may not exist</li>
+    <li><b>select</b> is used to query multiple records. The result is an array of 0, 1, or more entities</li>
+    <li><b>count</b> is used to count records</li>
+</ul>
+
+
+<h1>Escaping</h1>
+<p>It's common to use variables in query conditions. For instance, in the above example, you'll want to query an account by name instead of using the hardcoded <b>ffda</b> name. The <b>expr</b> attribute takes an XTK expression as a parameter, and <b>ffda</b> is a string litteral in an xtk expression.</p>
+
+<p>To prevent xtk ingestions vulnerabilities, you should not concatenate strings and write code such as expr: "@name = '" + name + "'": if the value of the name 
+  parameter contains single quotes, your code will not work, but could also cause vulnerabilities.
+</p>
+
+<p></p>
+<p class="ref">Find more details about escaping <a href="{{ site.baseurl }}/escaping.html">here</a>.</p>
+
+
+
+
+<h1>Pagination</h1>
+<p>Results can be retrieved in different pages, using the <b>lineCount</b> and <b>startLine</b> attributes. For instance, retrieves profiles 3 and 4 (skip 1 and 2)</p>
+
+<pre class="code">
+const queryDef = {
+    schema: "nms:recipient",
+    operation: "select",
+    <span class="emphasis">lineCount: 2</span>,
+    <span class="emphasis">startLine: 2</span>,
+    select: {
+        node: [
+            { expr: "@id" },
+            { expr: "@email" }
+        ]
+    }
+}
+const query = NLWS.xtkQueryDef.create(queryDef);
+const recipients = await query.executeQuery();
+console.log(JSON.stringify(recipients));
+</pre>
+
+<p class="warning">
+    Campaign will automatically limit the number of row returned by a query to <b>200</b>. The reason for this limit is that
+    all the data returned by a query is stored in memory in the application server, but is also sent over the network to
+    the SDK or API client, which also stores the data in memory. Storing more than a few hundred rows is generally not a 
+    good idea. Using the <b>QueryDef</b> API to handle large amounts of data is not a good idea either, it's better to 
+    use workflow instead. Worfklows are made to process large amounts of data, up to hundreds of millions of rows, whereas
+    queries are not meant to handle more than a few hundred rows.
+</p>
+
+<p>
+    More advanced pagination also need a <b>orderBy</b> clause to ensure that results are consistent. If not using an orderBy
+    clause, the query does not quarantee the ordering of the results, and subsequent calls are not quaranteed to 
+    return consistent pages. This example uses the name attribute to sort delivery mappings and returns the first 2
+    records.
+</p>
+
+<pre class="code">
+const queryDef = {
+    schema: "nms:deliveryMapping",
+    operation: "select",
+    <span class="emphasis">lineCount: 2</span>,
+    select: {
+        node: [
+            { expr: "@id" },
+            { expr: "@name" }
+        ]
+    },
+    <span class="emphasis">
+    orderBy: { node: [
+        {expr: "@name"}
+    ]}</span>
+    };
+</pre>
+
+
+<h1>Conditionnal queries</h1>
+
+<p>
+    Some Campaign attributes depend on the installed packages. For instance, the mobile package will add attributes to
+    various schemas so that Campaign can handle push notifications. I you need to write generic code that can adapt
+    whether the mobile package is installed or not, you can use the <b>hasPackage</b> function to 
+    conditionally add nodes to the query.
+</p>
+
+<pre class="code">
+if (client.application.hasPackage("nms:mobileApp")) {
+    queryDef.select.node.push({ expr: "@blackListAndroid" });
+}  
+</pre>
+
+
+
+
+<h1>Select all fields</h1>
+
+<p>
+    For some objects, such as deliveries and workflows, it can be painful to have to list all the attributes that we want
+    to retreive, as there could be hundreds. The query provides a mechanism to select all attributes, a bit like
+    a SELECT * would do in SQL. However, it involves an extra API call <b>xtk:queryDef#SelectAll</b> which means an
+    additional round-trip to the server
+</p>
+
+<pre class="code">
+const queryDef = {
+    schema: "xtk:option",
+    operation: "get",
+    where: {
+        condition: [
+            { expr:`@name='XtkDatabaseId'` }
+        ]
+    }
+    }
+    const query = NLWS.xtkQueryDef.create(queryDef);
+    await query.selectAll(false);
+    const databaseId = await query.executeQuery();
+</pre>
+<p class="caption">Querying all attributes of the xtk:option schema</p>
+
+
+
+
+<h1>Generating the SQL of a query</h1>
+
+<p>
+    The queryDef API also lets you generate the SQL for a query, using the <b>BuildQuery</b>.
+</p>
+
+
+<pre class="code">
+const sql = await query.buildQuery();
+console.log(">> SQL query: " + sql);
+</pre>
+
+
+<p>
+    The <b>BuildQueryEx</b> methods will also return the SQL and also metadata (data type) about each select field.
+</p>
+
+<pre class="code">
+const sql = await query.buildQueryEx();
+console.log(`>> SQL queryEx: "${sql[0]}"`);
+console.log(`>> Format string: "${sql[1]}"`);
+</pre>
+
+
+
+<h1>The analyze option</h1>
+
+<p>
+    The query uses the <b>analyze</b> option to return user friendly names for enumerations. 
+    In this example, we use the exclusionType attribute of the target mappings schema. Without the analyze flag, the query will
+    return the numeric value of the attribute (for example 2). With the flag, the query will still return the numeric value,
+    but will also return the string value of the attribute and its label. It will use addition JSON attributes named
+    "exclusionTypeName" and "exclusionTypeLabel", using the "Name" and "Label" suffixes.`,
+</p>
+
+<pre class="code">
+const queryDef = {
+    schema: "nms:deliveryMapping",
+    operation: "get",
+    select: {
+        node: [
+            { expr: "@id" },
+            { expr: "[storage/@exclusionType]", <span class="emphasis">analyze: true</span> },
+        ]
+    },
+    where: {
+        condition: [
+            { expr:`@name='mapRecipient'` }
+        ]
+    }
+}
+query = NLWS.xtkQueryDef.create(queryDef);
+mapping = await query.executeQuery();
+</pre>
+

package/docs/xtkSchema.html

@@ -0,0 +1,39 @@
+---
+layout: page
+title: The Schema API
+---
+
+
+
+<p>Reading schemas is a common operation in Campaign. The SDK provides a convenient functions as well as caching for efficient use of schemas.</p>
+<p>In addition, have a look at the <a href="{{ site.baseurl }}/application/html">Application</a> object which contains an object model for accessing and traversing schemas</p>
+
+<pre class="code">
+const schema = await client.getSchema("nms:recipient");
+console.log(JSON.stringify(schema));
+</pre>
+
+<p>A given representation can be forced</p>
+<pre class="code">
+const xmlSchema = await client.getSchema("nms:recipient", "xml");
+const jsonSchema = await client.getSchema("nms:recipient", "SimpleJson");
+</pre>
+
+<p>System enumerations can also be retreived with the fully qualified enumeration name</p>
+<pre class="code">
+const sysEnum = await client.getSysEnum("nms:extAccount:encryptionType");
+</pre>
+
+<p>or from a schema</p>
+<pre class="code">
+const schema = await client.getSchema("nms:extAccount");
+const sysEnum = await client.getSysEnum("encryptionType", schema);
+</pre>
+
+<p>Get a source schema</p>
+<pre class="code">
+var srcSchema = await NLWS.xtkPersist.getEntityIfMoreRecent("xtk:srcSchema|nms:recipient", "", false);
+console.log(JSON.stringify(srcSchema));
+</pre>
+
+