Neolane v5.1 - Configuration Guide

Configuration Guide
Neolane v5.1
This document, and the software it describes, are provided subject to a License Agreement and may not be used or copied outside
of the provisions of the License Agreement. No part of this publication may be reproduced, stored in a retrieval system, or transmitted,
in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of
Neolane.
This document may be revised without notice. Neolane does not guarantee the accuracy nor the completeness of the information
contained within this document. References to company names are intended to be ficticious and for illustrative purposes only and do
not refer to any real-world company.
Any brands cited are the property of their respective owners. Windows is the registered trademark of Microsoft Corporation in the
United States and other countries. Java and Solaris are trademarks of Sun Microsystems, Inc. in the United States and in other
countries. Linux is the registered trademark of Linus Torvalds in the United States and in other countries. This product includes
software developed by Apache Software Foundation (http://www.apache.org/).
For any questions or queries, please send a message to the following address: doc@neolane.com.
Unless mentioned otherwise, company names, logos, brands and logos cited in this document are the property of Neolane S.A. or its
subsidiaries. They may not be used without prior written authorization from Neolane.
Table of Contents
Neolane v5.1 - Configuration Guide
Neolane v5.1 - Configuration Guide | 3

Neolane
4 | © Neolane 2010
Neolane
6 | © Neolane 2010
Neolane
8 | © Neolane 2010
CHAPTER 1
Neolane data model
Table of Contents
Accessing the data schemas in Neolane . . . . . . . . . . . . . . . . . 10
General information . . . . . . . . . . . . . . . . . . . . . . . 11
Physical and logical data . . . . . . . . . . . . . . . . . . . . . 11
Working tables . . . . . . . . . . . . . . . . . . . . . . . . 11
Table structure . . . . . . . . . . . . . . . . . . . . . . . . 11
Auto-incrementing primary keys . . . . . . . . . . . . . . . . . . 11
Zero-ID record . . . . . . . . . . . . . . . . . . . . . . . . 12
"Deleted" field . . . . . . . . . . . . . . . . . . . . . . . . 12
Track changes . . . . . . . . . . . . . . . . . . . . . . . . 12
Description of the main tables . . . . . . . . . . . . . . . . . . . . 14
Simplified diagram . . . . . . . . . . . . . . . . . . . . . . . 14
NmsRecipient . . . . . . . . . . . . . . . . . . . . . . . . . 14
NmsGroup and NmsRcpGrpRel . . . . . . . . . . . . . . . . . . . 15
NmsService, NmsSubscriptions and NmsSubHisto . . . . . . . . . . . . 15
NmsDelivery . . . . . . . . . . . . . . . . . . . . . . . . . 16
NmsBroadLog . . . . . . . . . . . . . . . . . . . . . . . . . 17
NmsTrackingLog and NmsTrackingUrl . . . . . . . . . . . . . . . . . 19
XtkFolder . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Description of Neolane's main modules . . . . . . . . . . . . . . . . . 21
Delivery and tracking . . . . . . . . . . . . . . . . . . . . . . 21
Delivery to mobile channels . . . . . . . . . . . . . . . . . . . . 22
Response management . . . . . . . . . . . . . . . . . . . . . 23
Offer management . . . . . . . . . . . . . . . . . . . . . . . 26
Campaign management . . . . . . . . . . . . . . . . . . . . . 29
Neolane v5.1 - Configuration Guide - Neolane data model | 9

This chapter presents the architecture of the main business tables rather than internal operating
tables, as well as the specifics of the Neolane data model. The aim is to help the user understand
the data model in order to analyze data, configure new reports, perform targeting based on reactions
to previous deliveries, export data linked to a delivery and synchronize data with other systems.
Accessing the data schemas in Neolane

For an exhaustive description of the data model, please refer to the Documentation tabs of the
data schemas:
10 | © Neolane 2010
General information
Before dealing with the data model as such, we will cover some general information.
Physical and logical data

Physical data (SQL vision) is inferred from logical schemas (XML vision).
As a consequence, a logical schema does not always give rise to a physical schema. As a result,
some data or parts of schemas are described in XML elements and are only stored in a single
XML field. This is the case with the link between deliveries and typology rules for HTML content,
for example.
Moreover, some tables are polymorphic; such as plans and programs stored in the same
physical table (xtkFolder), campaigns and deliveries containing instances, and delivery templates.
In addition, some data is not present in the datamodel and can only be found in the XML
metadata. This is the case for system enumerations (sysenum), for example.
Working tables
Working tables are created, then destroyed during application phases. The name and structure
of some tables are defined at run time (data management, targeting workflows, etc.), while
others are persistent dynamic tables (lists, answers to a survey, simulation results).
Table structure
Some table structures can be complex. For example:
self-referent tables that point to themselves, such as campaign and budget tables;
hierarchical tables such as xtkFolder for which access to information requires using the
full name (fullname).
Auto-incrementing primary keys

The primary key (ID) for most Neolane tables is an auto-generated 32-bit integer (for schemas
with the autopk="true" property, refer to the Extending schemas [page 37] section).
All these primary keys use the same XtkNewId sequence. When creating the database, this
sequence is initialized to 1000, the first 1000 identifiers are reserved. As a result, if for any
reason, you have to "hard code" an identifier, you can use an identifier greater than 1000 to
avoid any risk of conflict.
If necessary, you can use negative values.
Note:
The keys of the NmsBroadLog and NmsTrackingLogXXX tables have their own sequence.

Zero-ID record
For all the tables that use our sequence as a primary key, a record with the value 0 is inserted
on creation. This zero-ID record is used to avoid outer joins, which are not efficient for high-volume
tables. By placing the value 0 in the foreign key of a table when the data item is not populated, a
join is made with this zero-ID record, which contains no data. All queries made via the application
ignore this record in results returned. You only need to watch out for this if you implement SQL
extraction procedures on the Neolane tables.
Tip:
Within workflows, you can configure the management of additional data and disable filtering. To do
this, edit additional data (in the Query or Enrichment boxes, for example), click the Advanced
settings link and check the Disable the automatic filtering of records with 0 IDs option.
"Deleted" field
Certain tables contain an iDeleteStatus field (NmsDelivery, NmsService and NmsSubscription
in particular). This field is used for managing the and performing time-consuming
deletions during the night.
The value 1 means that the record will be deleted by the clean up workflow (cleanup) next time it
is executed (mostly scheduled to be executed every night). Records linked with integrity own are
also deleted (refer to Extending schemas [page 37]).
As a consequence, you should consider these records as destroyed even if they have not yet been
physically deleted from their tables.
In all the queries configured in the application, an iDeleteStatus = 0 clause is added implicitly.
However, when writing queries directly in SQL, you must take this field into consideration.
In the case of deliveries (NmsDelivery table), the value 2 means that the record is in the
. Deleted deliveries are placed there by default and can be restored by the user if necessary. By
default, the cleanup task deletes the delivery after seven days. In this case, the tsDelete field gives
the date on which the record was moved to the recycle bin.
Track changes
Certain reserved field names enable you to track the creation and modification of certain records:
tsCreated contains the creation date,
tsLastModified contains the last modification date,
12 | © Neolane 2010
iCreatedById contains the identifier of the operator who created the record (foreign key
of a link to XtkOperator),
iModifiedById contains the ID of the last operator who modified the record (foreign key
of a link to XtkOperator).
These fields are added in the schemas using the auditTrail aggregate. Other schemas only
use certain fields. For example NmsRecipient contains tsCreated and tsLastModified only.
These fields are populated automatically for all creations and modifications made by the
application: input interface, imports, web forms, etc.
Warning:
The name of each field in the XML schema triggers this behavior, not the SQL names.
Creation and modification dates can only be changed via the Neolane console. Updates, deletions
or insertions carried out in the database and not via the console will have no effect on these
dates.

Description of the main tables
Simplified diagram
The following is a diagram showing the joins between the main business tables of the Neolane data
model with the main fields shown for each.
NmsRecipient
This table coincides with the nms:recipient schema.
It is the default table used for the recipients of deliveries. As a result, it contains the information
required for deliveries via the various channels:
14 | © Neolane 2010
sEmail: email address.
iEmailFormat: preferred format for emails (1 for Text, 2 for HTML and 0 if undefined).
sAddrAdditionnalGeo, sAddrAdditionnalRcp, sAddrStreet, sAddrSpecial,
sAddrZipCode, sCity are used to build the postal address (in keeping with the XPZ 10-011
AFNOR standard from May 1997).
sPhone, sMobilePhone, sFax contain the phone, mobile phone and fax numbers
respectively.
iBlackList is the default opt-out flag used for the profiles (1 means "unsubscribed", 0
otherwise).
The iFolderId field is the foreign key that links the recipient to its execution folder. Refer to
the description of the XtkFolder table below for further details.
The sCountryCode field is the 3166-1 Alpha 2 ISO code (2 characters) of the country
associated with the recipient. This field is actually a foreign key on the country reference table
(NmsCountry), which contains the country labels and other country code data. If the country
is not populated, the value 'XX' is stored (and is used in place of a zero ID record).
sAccount and sOrigin are indexed description fields. They are designed to contain an external
recipient ID (for example, a customer identifier) and a trace of the origin of the profile data.
NmsGroup and NmsRcpGrpRel

These tables coincide with the nms:group and nms:rcpGrpRel schemas.
They enable you to create statistical groups of recipients. There is a many-to-many relation
between recipients and groups. For example, one recipient can belong to several groups and
one group can contain several recipients. Groups can be created manually, via an import or
via delivery targeting. Groups are often used as delivery targets. There is a unique index on
the field representing the internal name of the sName group. The group is linked to a folder
(The key is iFolderId. See the description of the XtkFolder table below).
The NmsRcpGrpRel relationship table only contains the two fields corresponding to the
identifiers of the iRecipientId and iGroupId linked tables.
NmsService, NmsSubscriptions and NmsSubHisto

These tables coincide with the nms:service, nms:subscription and nms:subHisto schemas.
These tables enable you to manage subsriptions and unsubscriptions to information
services. Services are entities similar to groups (static groups of recipients) but they convey
more information and enable you to manage subscriptions and unsubcriptions using web forms.
Note:
For further information on this topic, refer to the User Guide.
There is a unique index on the field representing the internal name of the sName service.
The service is linked to a folder (The key is iFolderId. See the description of the XtkFolder
table below). Finally, the iType field specifies the delivery channel of this service (0 for email,
1 for SMS, 2 for telephone, 3 for direct mail and 4 for fax).
The NmsSubscription relationship table is similar to NmsRcpGrpRel but may contain other
information in addition to the relationship. In particular, the sAddressSpecific and

iEmailFormat fields make it possible to overload the address (email, mobile number, etc.) depending
on service type, profile and email format for deliveries using the service.
Finally, if the subscriptions are managed using web forms or the interface of the application, all
susbcriptions and unsubscriptions are historized in the NmsSubHisto table. The iAction field specifies
the action (0 for unsubscription and 1 for subscription) performed on the date stored in the tsDate
field.
NmsDelivery
This table coincides with the nms:delivery schema.
Each record in this table represents a delivery action or a delivery template. It contains all the
necessary parameters for performing deliveries (the target, the content, etc.). Delivery (broadcast)
logs (NmsBroadLog) and associated tracking URLs (NmsTrackingUrl) are created during the
analysis phase (see below for further details on both of these tables).
There is a unique index on the field representing the internal name of the sInternalName delivery
or scenario. The delivery is linked to an execution folder (The foreign key is iFolderProcessId. See
the description of the XtkFolder table below).
The table contains several foreign keys, including in particular:
iDeliveryProviderId: Routing service provider to be used. This is an external "Routing" account
(NmsExtAccount table, iType = 3).
iMappingId: Delivery mapping (NmsDeliveryMapping table. Refer to the Using an existing
recipient table [page 151] section)
iTypologyId: Campaign typology (NmsCampaignTypology table), which is a set of rules to
verify the delivery parameters and exclusions of recipients to be applied.
The iState field gives the current status of the delivery. The possible statuses are as follows:
0 - "Being edited": the delivery is being created by the user (only possible value for a scenario).
11 - "Targeting pending": the delivery analysis was requested by a user but is not yet effective.
12 - "Count in progress": delivery preparation in progress.
13 - "Arbitration in progress": application of typology rules for a delivery in progress.
15 - "Target ready": target estimation complete.
21 - "Personalization pending": calculation of the personalization blocks for the delivery taken
into account. In the Distributed Marketing application, child-campaigns keep this state as long
as the calculation of their campaign personalization is in progress.
22 - "Personalization in progress": calculation of personalization blocks in progress for an email/SMS
delivery or file export with personalization data for a direct mail delivery.
25 - "Finalized message": delivery ready to be sent.
37 - "Count or personalization fail": the target was not specified or the personalization blocks
could not be inserted into the message.
45 - "Ready for delivery": analysis finished without errors, messages prepared. Delivery awaiting
confirmation.
51 - "Start pending": send request for the deferred delivery taken into account.
55 - "In progress": sendings are in progress.
61 -"Recovery pending": sending was attempted at least once for each message, but some failed.
One or more recoveries are scheduled (tsNextRetry shows the next recovery date).
62 - "Recovery in progress": recovery is in progress on failed messages.
16 | © Neolane 2010
71 - "Pause requested": delivery paused by an operator.
72 -"Pause in progress": a pause has been requested by a user but is not yet effective.
75 -"Paused": sendings have been paused by a user.
81 -"Stop requested": delivery stopped by an operator.
82 -"Stop in progress": stopping has been requested by a user but is not yet effective.
85 -"Stopped": the delivery has been stopped (and may not be started again).
87 -"Failed": the delivery could not be sent.
95 -"Finished": the delivery is finished. It may be edited but not altered.
100 -"Deleted": only used in mid-sourcing mode to extend destruction to the mid-sourcing
server.
Statuses up to and including 15 deal with deliveries that have not yet started. Once the delivery
has been validated with success, the status moves to a value higher than 15. Statuses 0, 2,
3, 5, 6 and 15 enable the user to edit the delivery parameters and start the analysis.
The iIsModel field indicates whether it is a template or a delivery action (1 for a scenario, 0
otherwise). In case of a template, the iFolderProcessId field is the identifier of the folder to
which the template belongs and iCampaignProcessId that of the execution folder in which
the deliveries created from this template are placed.
Below is a list of other important fields:
iMessageType - Delivery medium: 0 for e-mail, 1 for SMS, 2 for telephone, 3 for direct
mail and 4 for fax.
iDeliveryMode - Delivery mode: 0 when performed by a third-party router (the delivery
creates a file of the messages to be sent), 1 if the execution is handled directly by the
platform, 3 if the delivery is handled by another remote Neolane platform in "mid-sourcing"
mode.
iFCP -message type: 1 if it is a "proof", 0 otherwise.
iMidSourcing - mid-sourcing: 1 if it is a slave version of a delivery on the mid-sourcing
server.
sDeliveryCode - Indexed text field to associate an external identifier with the delivery.
Below is a list of the most important date fields used in deliveries:
tsCreated - Creation date of the delivery (or of the scenario).
tsLastModified - Date of the last modification (manual or via an automatic process).
tsExpiration - Start date.
tsValidity - Validity end date: Beyond this date no more messages will be sent or retries
made.
tsWebValidity - Validity end date for online resources: For email deliveries, mirror pages
expire after this date.
NmsBroadLog
This table coincides with the nms:broadLog schema.
It contains one record per targeted recipient for each delivery. The records are created
when the delivery is analyzed. The table contains the messages sent, the failed messages,
the messages to be processed and the ignored addresses (blacklisted, quarantined, etc.)

The table contains the iDeliveryId and iRecipientId identifiers, which link the logs to their delivery
(NmsDelivery) and their recipient (NmsRecipient). In reality, the iRecipientId field can be set
to 0 if the delivery concerns another table. Refer to Using an existing recipient table [page 151].
The iStatus field gives the meaning of the delivery log:
0 - "ignored": The recipient was excluded from the messages to be sent, the iFailureReason
field provides the reason.
1 - "sent": The message was sent successfully.
2 - "failed": The message failed (warning: there may be further attempts). The sMessage field
contains the error message.
6 - "pending": The message has been prepared but not yet processed by the delivery server.
7 - "delivery canceled": The delivery was stopped before the message could be processed.
8 - "prepared": The customized content (PDF) is calculated and need to be sent to the routing
service provider (direct mail only).
There are 3 other statuses concerning SMS only:
3 - Pending transmission to SMS-C
4 - Sent to SMS-C
5 - Received on mobile
The iFailureReason field gives the failure reason for logs with statuses equal to "ignored", "failed"
or "delivery cancelled" (0, 2 or 7):
0 - Undefined
1 - Unknown user
2 - Invalid domain
3 - Unreachable
4 - Account disabled
5 - Inbox full
6 - Not connected
7 - Address not populated (skipped during analysis)
8 - Address blacklisted (skipped during analysis)
9 - Address in quarantine (skipped during analysis)
10 - Duplicate (skipped during analysis)
11 - Excluded by a SQL rule (skipped during analysis)
12 - Excluded by arbitration (skipped during analysis)
13 - Delivery cancelled
14 - Bad-quality address (skipped during analysis, DM paper only)
15 - Unqualified address (skipped during analysis, direct mail only)
20 - Refused
25 - Error ignored
The iFailureType field gives an indication of the severity of the "failed" messages (status 2):
0 - Unknown
1 - a "soft" error (soft bounce), which may be temporary (such as "invalid domain"). As a result,
there will be retries for this message.
18 | © Neolane 2010
2 - a "hard" error (hard bounce) with an explicit message (such as "unknown user"). The
address will be quarantined and there will be no retries.
3 - an "ignored" error. The error is ignored by the quarantine mechanism.
sAddress indicates the address used for the delivery (e-mail, mobile number, etc.), in other
words, its value at analysis time. In case of a direct mail delivery, the postal address lines are
stored in the NmsBroadLogPostalAddress table (whose foreign key is
iBroadLogPostalAddressId).
The tsEvent field gives the date of the event coinciding with the log (for example, delivery
date of the message) and tsLastModified gives the date of its last modification in the database.
In the case of deliveries on tables other than NmsRecipient, please refer to Using an existing
recipient table [page 151].
NmsTrackingLog and NmsTrackingUrl

These tables coincide with the nms:trackingLog and nms:trackingUrl schemas.
The NmsTrackingLog table contains a record for each click made by a recipient on a
tracked link.
Each tracking log is linked to a delivery (iDeliveryId key on NmsDelivery), a message
(iBroadLogId key on NmsBroadLog) and a URL (iUrlId key on NmsTrackingUrl). The
log also stores the date of the click in tsLog.
The NmsTrackingUrl table provides information on the meaning of the URL. Records are
linked to delivery (iDeliveryId key) except for web, transaction and open URLs. This means
that when a delivery is analyzed, a record is created in this table for each link appearing in the
content of the message. As a consequence, a given source URL (for example,
http://www.neolane.com/) can have more than one record in the NmsTrackingUrl table:
one for each time http://www.neolane.com/ is used in an content (for which tracking is
activated).
sTagId is a text idendifier of the tracked URL used by the tracking server.
iType specifies the URL type:
1 - "Mail": Classic link in the content of an e-mail.
2 - "Opening": Coincides with the opening of an HTML message (there is only one URL of
this type).
3 - "OptOut": An unsubscription link.
4 - "Web": "webtracking" or "post-click" link corresponding to a Web page.
5 - "Transaction": "webtracking" link corresponding to a transaction.
6 - "Mirror page": Link to the mirror page.
sSource contains the source URL (for example, "http://www.neolane.com/"), sLabel is the
associated label used for grouping URLs with the same meaning in reports and sCategory is
used for sorting the URLs for reporting purposes.
Other fields in the NmsTrackingLog table (sSourceId, sSourceType and sUserAgent)
contain additional information on clicks.
XtkFolder
This table coincides with the xtk:folder schema.

It contains all the folders in the tree visible in the Navigation tab of the console.
The folders are typed: The value of the sModel field specifies the type of data that can be contained
in the folder. This field also enables the client console to display the data correctly with the
corresponding forms. The possible values for this field are defined in the navTree. For further
information, refer to Extending schemas [page 37].
The following is a list of the most important standard values:
Folder model (sModel) Table of the data Description

in the folder
xtkFolder Structure folder without data
nmsRecipient NmsRecipient Folder containing recipients
nmsGroup NmsGroup Folder containing recipient groups
nmsSetOfServices NmsService Folder containing information services
nmsScenario NmsDelivery Folder containing delivery scenarios
nmsDelivery NmsDelivery Folder containing delivery actions
nmsExtAccount NmsExtAccount Folder containing external accounts
nmsWebTracking NmsTrackingUrl Folder containing declared Web-tracking
URLs
The tree is managed by the iParentId and iChildCount fields. The sFullName field gives the full
path of the folder in the tree. Finally, there is a unique index on the field representing the internal
name of the sName folder.
20 | © Neolane 2010
Description of Neolane's main modules
Delivery and tracking
Figure 1.1. Simplified diagram of delivery and tracking
NmsRecipient
This table coincides with the nms:recipient schema.
Refer to NmsRecipient [page 14].
NmsDelivery
This table coincides with the nms:delivery schema.
Refer to NmsDelivery [page 16].

NmsBroadLog and NmsExcludeLog
These tables coincide with the nms:broadLogRcp and nms:excludeLogRcp schemas.
NmsBroadLogRcp contains the contacts of the delivery. NmsExcludeLogRcp contains the contacts
rejected during the analysis of the initial target.
Refer to NmsBroadLog [page 17].
NmsBroadLogMsg
This table coincides with the nms:broadLogMsg schema.
It is an extension of the delivery log table.
Refer to NmsBroadLog [page 17].
NmsTrackingUrl
Refer to NmsTrackingLog and NmsTrackingUrl [page 19].
NmsTrackingLog
Refer to NmsTrackingLog and NmsTrackingUrl [page 19].
NmsTrackingStats
This table coincides with the nms:trackingStats schema.
It contains the aggregates on tracked logs.
Delivery to mobile channels

Status of messages sent via SMS according to NetSize
This table coincides with the error statuses created by NetSize after the iFailureReason enumeration
of the nms:broadLogMsg delivery logs table.
Error code Values in nms:broad- NetSize values

LogMsg
0 Undefined Undefined error (non-quali-
fied by NetSize)
1 User unknown Number unknown
3 Unreachable Other error
5 Inbox full SIM full
6 Not connected Mobile without coverage
22 | © Neolane 2010
Error code Values in nms:broad- NetSize values
LogMsg
20 Rejected Blacklisted number
Response management
Figure 1.2. Simplified diagram of response management
NmsRemaHypothesis
This table coincides with the nms:remaHypothesis schema.
It contains the definition of the measurement hypothesis, namely:
General information
Internal name: sInternalName.
Label: sLabel.
Nature: sNature.
Link folder: iFolderId.
Status: iStatus, with the following values:
- 0 - Edit
- 1 - Pending
- 2 - Execution in progress
- 3 - Cancel in progress
- 4 - Canceled
- 5 - Finished
- 6 - Finished with errors

- 7 - Pause in progress
- 8 - Paused
- 9 - Server shutdown in progress
Execution parameters
Priority: iPriority, with the following values:
- 0 - Low
- 1 - Average
- 2 - High
Execution period: tsStartDelay, tsEndDelay.
Scheduler (XML definition).
Execution context (information stored in XML)
Populates the tables and fields to be taken into account for measurement calculation, namely:
the nms:remaMatchRcp reaction log storage schema,
the transaction table schema (purchases for example),
the querying schema: enables you to define the start table of the hypothesis conditions,
the links to individuals: enables you to identify the individual based on the querying schema,
the transaction date: this field is not mandatory but we recommend that you use it to restrict the
calculation perimeter,
the transaction amount: optional field for automatically calculating revenue indicators.
Scope of the hypothesis (information stored in XML)
Filtering of the hypothesis based on the table of the querying schema.
Hypothesis overload script (information stored in XML)
JavaScript code which enables you to overload the content of the hypothesis during execution.
Measurement indicators
The following indicators are updated automatically during hypothesis execution:
Number of reactions: iTransaction
Number of lines in the reaction logs table
Number of contacted: iContactReacted.
Distinct number of targeted contacts in the hypothesis.
Control group count: iProofReacted.
Distinct number of targeted control group contacts in the hypothesis.
Contacted response rate: dContactReactedRate.
Response rate of the contacts targeted in the hypothesis.
Response rate of the control group: dProofReactedRate.
Response rate of the hypothesis control group.
Total revenue of population contacted: dContactReactedTotalAmount.
Total revenue of the targets contacted in the hypothesis.
Average revenue of control group: dContactReactedAvgAmount.
Total revenue of the contacted.
Total revenue of the control group: dProofReactedTotalAmount.
24 | © Neolane 2010
Total revenue of the hypothesis control group.
Average revenue of control group: dProofReactedAvgAmount.
Total revenue of the hypothesis control group.
Total margin of contacts: dContactReactedTotalMargin.
Total margin of contacts targeted in the hypothesis.
Average margin per contact: dContactReactedAvgMargin.
Total margin of contacts targeted in the hypothesis.
Total margin of control group: dProofReactedTotalMargin.
Total margin of control group targeted in the hypothesis.
Average margin of control group: dProofReactedAvgMargin.
Total margin of control group targeted in the hypothesis.
Additional revenue: dAdditionnalAmount.
(Average revenue of contacted-Average revenue of control group)*Number of contacted
Additional margin: dAdditionnalMargin.
(Average margin of contacted-Average margin of control group) / number of contacted
Average cost per contact (SQL expression).
Calculated cost of the delivery / Number of contacted.
ROI (SQL expression)
Calculated cost of the delivery / Total margin of contacted
Effective ROI (SQL expression)
Calculated cost of the delivery / Additional margin.
Significance: iSignificativy(SQL expression).
Contains values 0 to 3 depending on the significance of the campaign.
NmsRemaMatchRcp
NmsRemaMatchRcp This table coincides with the nms:remaMatchRcp schema.
It contains a record representing an individual's reaction to a given hypothesis. These records
were created during hypothesis execution.
The following data is contained in this table:
Hypothesis ID: iHypothesisId.
Delivery log ID: iBroadLogId.
Proposition ID: iPropositionId.
Control group: iControlGroupId.
For further information, refer to Response management [page 229].

Offer management
Figure 1.3. Simplified offer management diagram
NmsOffer
This table coincides with the nms:offer schema.
It contains the definition of each marketing offer.
General information
Internal name: sName.
Label: sLabel.
Offer code: sCode.
ID of the linked category (XtkFolder): iCategoryId
Validity
Activity flag: iActive.
Start of the validity period: tsStart.
End of the validity period: tsEnd.
26 | © Neolane 2010
NmsPropositionRcp
This table coincides with the nms:propositionRcp schema.
It contains the cross-channel log of marketing propositions sent to each individual. The record
is created when a proposition is prepared or effectively made to an individual.
General information
Offer ID: iOfferId.
Recipient ID: iRecipientID.
Event date: tsEvent.
- 0 - Generated
- 1 - Presented
- 2 - Interesting
- 3 - Accepted
- 4 - Delayed
- 5 - Rejected
Interaction ID: iInteractionId
Location ID: iOfferSpaceId
ID of the associated delivery log: iBroadLogId
Weight of the proposition: dWeight
Rank of the proposition: iRank.
NmsOfferSpace
This table coincides with the nms:offerSpace schema.
It contains the definition of locations on which propositions are made.
Internal name: sName
Label: sLabel
Channel: iChannel
Name of the interaction schema: sInputSchema
Name of the representation schema: sOutputSchema
Environment ID (XtkFolder): iEnvId
Linked folder ID: iFolderId
Value of the initial proposition status: iDefaultStatus
NmsOfferContext
This table coincides with the nms:offerContext schema.
It contains additional criteria on the applicability of the proposition as well as the definition of
the weight calculation formula.
General information
Internal name: sName
Label: sLabel
Proposition ID: iOfferId

Location ID: iSpaceId
Validity
Activity flag: iActive
Start of the validity period: tsStart
End of the validity period: tsEnd
NmsOfferView tables
There is one table per channel:
Website: NmsWebOfferView (nms:webOfferView schema)
Call center: NmsCallCenterOfferView (nms:callCenterOfferView schema)
Email: NmsEmailOfferView (nms:emailOfferView schema)
Direct mail: NmsPaperOfferView (nms:paperOfferView schema)
Mobile: NmsMobileOfferView (nms:mobileOfferView schema)
Each table contains representations of the propositions on a channel.
General information
Offer ID: iOfferId
Location ID: iSpaceId
Activity flag: iActive
28 | © Neolane 2010
Campaign management
Figure 1.4. Simplified campaign management diagram
NmsOperation
this table coincides with the nms:operation schema. It contains the data of marketing
campaigns.
General information
Single numerical internal primary key: iOperationId.
Unique internal name: sInternalName.
Label: sLabel.
Nature: sNature.
Linked program: iProgramId. This field is a link towards the nms:operation table.
Status (calculated expression), with the following values:
-0- Being edited (name="edition" value="0"/>)
-1- Started
-2- Finished
-3- Cancel in progress
-4- Canceled
-5- Evaluation
Assigned operator: iOwnerId. This field is a link towards the XtkOperator table.

Schedule: tsStart and tsEnd.
Advanced parameters
Main channel: iMessageType.
Linked campaign: iLinkedOperationId.
Process execution (XML structure).
Seed addresses (XML structure).
Control group (XML structure).
Approval parameters
Enable content approval: iUseContentValidation.
Enable target approval: iUseTargetValidation.
Enable budget approval: iUseBudgetValidation.
Enable extraction approval: iUseExtractionValidation.
Enable the sending and approval of proofs: iUseFCPValidation.
Reviewers and approval schedule (XML structure).
Approval mode: iValidationMode, with the following values:
-0- Automatic
-1- Manual
Do not enable notification sending: iDisableNotification.
Enable individual approval of each associated delivery: iUseLinkedDeliveryValidation.
Enable the automatic creation of approval tasks: iUseTaskCreation.
Budget parameters
Allocation: iBudgetId.
Commitment level: iCommitmentLevel, with the following values:
-0- Planned
-1- Reserved
-2- Commited
Process status: iBudgetStatus, with the following values:
-0- Being edited
-1- Defined
-2- Carried out
Estimated cost: dEstimatedCost.
Actual cost: dRealCost.
Calculated cost: dComputedCost.
Fixed cost: dFixedCost.
NmsDeliveryOutline
This table coincides with the nms:delivryoutline schema. It contains the extended properties of
the delivery (delivery outline).
Unique internal primary key: iDeliveryOutlineId.
Unique internal name: sName.
Label: sLabel.
30 | © Neolane 2010
Description (xml memo).
Linked campaign: iOperationId. This field is a link towards the NmsOperation table.
Message type: iMessageType.
Estimated provisional cost: dEstimatedCost.
Breakdown of the estimated provisional cost (xml structure).
This table contains the attributes of one or more deliveries.
NmsDlvOutlineItem
This table coincides with the nms:dlvOutlineItem schema. It contains the articles of a
delivery outline.
Numerical internal primary key: iDlvOutlineItemId.
Label: sLabel.
Delivery outline: iDeliveryOutlineId. This field is a link towards the NmsDeliveryOutline
table.
Offer: iOfferId. This field is a link towards the NmsOffer table.
Marketing resource: iAssetId.
Type of item: iType, with the following values:
-0- Item
-1- Personalization fields
-2- Resource
-3- Offer
-100- Channel information
NmsDeliveryCustomization
NmsDeliveryCustomization This table coincides with the nms:deliveryCustomization schema.
It contains the personalization fields of a delivery.
Unique internal primary key: iDeliveryCustomizationId.
Label: sLabel.
Outline item: iDlvOutlineItemId. This field is a link towards the NmsDlvOutlineItemI
table.
Delivery outline: iDeliveryOutlineId. This field is a link towards the NmsDeliveryOutline
table.
Associated folder: iFolderId. This field is a link towards the XtkFolder table.
Value: sValue.
Type of value: iType, with the following values:
-3- Integer
-5- Floating point
-6- Text
-7- Date + time

NmsDelivery
Refer to NmsDelivery [page 16].
NmsBudget
This table coincides with the nms:budget schema. It contains the data of a budget on a campaign,
a plan, a program, a task and/or deliveries.
Unique internal primary key: iBudgetId.
Label: sLabel.
Budget schedule: tsStart and tsEnd.
Linked budget: iAttachedBudgetId. this field is a link towards the NmsBudget table.
Amounts with the following values:
Allocated: dAllocated.
Spent: dExpensed.
Invoiced: dInvoiced.
Reserved: dReserved.
Planned: dPlanned.
Committed: dCommitted.
NmsDocument
NmsDocument This table coincides with the nms:document schema. It contains the marketing
documents of the campaign in the form of files (images, excel or word files, etc.)
Unique internal primary key: iDocumentId.
Label: sLabel.
Campaign: iOperationId. This field is a link towards the NmsOperation table.
XtkWorkflow
This table coincides with the xtk:workflow schema. It contains campaign targeting.
Unique internal primary key: iWorkflowId.
Label: sLabel.
Status: iState, with the following values:
-0- Being edited
-9- Request to start in simulation mode
-10- Start requested
-11- Started
-12- Pause requested
-13- Paused
-14- Resume requested
32 | © Neolane 2010
-15- Stop requested
-16- Stop in progress
-17- Restart requested
-18- Restarting
-20- Finished
XtkFolder
This table coincides with the xtk:folder schema. It contains the properties of a campaign
program.
Unique internal primary key: iWorkflowId.
Label: sLabel.
NmsTask
This table coincides with the nms:task schema. It contains the definition of a marketing task.
Unique internal primary key: iTaskId.
Label: sLabel.
Nature: sNature.
Task schedule: tsStart and tsEnd.
-0- Being edited
-1- Scheduled
-2- In progress
-3- Finished
-4- Canceled
Type: iType, with the following values:
-0- Task
-1- Checkpoint
-2- Grouping
Progress (as a %): iProgress.
Priority: iPriority.
Duration: iDuration
Realized load: tsRealizedDuration.
Planned load: tsPlannedDuration
Description (xml memo).
Approval type: iValidationType, with the following values:
-0- Target validation
-1- Content validation
-2- Budget validation

-3- Approval of extraction file
-4- Proof validation
-5- Approval of inclusion in the provisional calendar
-6- Available content
-7- External content validation
Associated folder: iFolderId. this field is a link towards the XtkFolder table.
Owner: iOwnerId. This field is a link towards the XtkOperator table.
Budget: iBudgetId. This field is a link towards the NmsBudget table.
Supplied service: iSupplierModelId. This field is a link towards the NmsSupplierModel table.
Dependent task: iDependingTaskId. This field is a link towards the NmsTask table.
Linked task: iLinkedTask. This field is a link towards the NmsTask table.
Delivery: iDeliveryId. This field is a link towards the NmsDelivery table.
Marketing resource: iAssetId. This field is a link towards the NmsAsset table.
NmsAsset
This table coincides with the nms:asset schema. It contains the definition of a marketing resource.
Unique internal primary key: iAssetId.
Label: sLabel.
Nature: sNature.
-0- Being edited
-1- Pending approval
-2- Approval in progress
-3- Approved
-4- Rejected
-5- Pending publication
-6- Publication in progress
-7- Published
-8- Canceled
Publication date: tsPublication.
Availability date: tsAvailability
Owner: iOwnerId. This field is a link towards the XtkOperator table.
NmsRemaHypothesis
This table coincides with the nms:remaHypothesis schema. It contains the definition of a
measurement hypothesis.
You may also refer to Response management [page 23].
Unique internal primary key: iRemaHypothesisId.
34 | © Neolane 2010
Label: sLabel.
Nature: sNature.
Delivery: iDeliveryId. This field is a link towards the NmsDelivery table.
Proposition: iOfferId. This field is a link towards the NmsOffer table.
Indicators
Number of reactions: iTransaction.
Number contacted iContactReacted.
Control group count: iProofReacted.
Contacted response rate: dContactReactedRate.
Response rate of the control group: dProofReactedRate.
Total revenue of population contacted: dContactReactedTotalAmount.
Total revenue of the control group: dProofReactedTotalAmount.
Total margin of contacted: dContactReactedTotalMargin.
Total margin of control group: dProofReactedTotalMargin.
NmsOffer
This table coincides with the nms:offer schema. It contains the properties of a marketing
offer.
You may also refer to Offer management [page 26].
Unique internal primary key: iOfferId.
Label: sLabel.
Offer schedule: tsStartDate and tsEndDate.
Activated: iActive.
Associated category: iCategoryId. This field is a link towards the XtkFolder table.

36 | Neolane v5.1 - Configuration Guide
CHAPTER 2
Extending schemas
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Basic principles . . . . . . . . . . . . . . . . . . . . . . . . 38
Syntax of schemas . . . . . . . . . . . . . . . . . . . . . . . 38
Identifying a schema . . . . . . . . . . . . . . . . . . . . . . 39
Schema structure . . . . . . . . . . . . . . . . . . . . . . . . 40
Description . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Data types . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Collections . . . . . . . . . . . . . . . . . . . . . . . . . 45
Referencing with XPath . . . . . . . . . . . . . . . . . . . . . 45
Building a string via the compute string . . . . . . . . . . . . . . . . 46
Database mapping . . . . . . . . . . . . . . . . . . . . . . . . 47
Description . . . . . . . . . . . . . . . . . . . . . . . . . . 47
XML fields . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Calculated fields . . . . . . . . . . . . . . . . . . . . . . . . 49
Feature fields . . . . . . . . . . . . . . . . . . . . . . . . . 49
Indexed fields . . . . . . . . . . . . . . . . . . . . . . . . . 50
Management of keys . . . . . . . . . . . . . . . . . . . . . . 51
Links: relation between tables . . . . . . . . . . . . . . . . . . . 54
Editing schemas . . . . . . . . . . . . . . . . . . . . . . . . . 59
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . 59
Example: creating a contract table . . . . . . . . . . . . . . . . . 60
Schema of an existing table or a view . . . . . . . . . . . . . . . . . 64
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . 64
Implementation . . . . . . . . . . . . . . . . . . . . . . . . 64
Neolane v5.1 - Configuration Guide - Extending schemas | 37

Accessing an external database . . . . . . . . . . . . . . . . . . . . . 66
Extending an existing schema . . . . . . . . . . . . . . . . . . . . . . 68
Updating the physical structure of the database . . . . . . . . . . . . . . . . 69
New field wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Structure of a schema . . . . . . . . . . . . . . . . . . . . . . . . . 74
Regenerating all schemas . . . . . . . . . . . . . . . . . . . . . . . . 74
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Extending a table . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Linked collection table . . . . . . . . . . . . . . . . . . . . . . . . 76
Extension table . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Overflow table . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Relationship table . . . . . . . . . . . . . . . . . . . . . . . . . 79
Seed list management . . . . . . . . . . . . . . . . . . . . . . . . . 80
Using an external table . . . . . . . . . . . . . . . . . . . . . . . . 80
Expression placeholders . . . . . . . . . . . . . . . . . . . . . . . 81
Introduction
This chapter describes how to configure extension schemas in order to extend the conceptual data
model of the Neolane database.
Basic principles
The physical and logical structure of the data carried in the application is described in XML. It obeys
a grammar specific to Neolane, called a schema.
A schema is an XML document associated with a database table. It defines data structure and describes
the SQL definition of the table:
The name of the table,
Fields,
Indexes,
Links with other tables,
It also describes the XML structure used to store data:
Elements and attributes,
Hierarchy of elements,
Element and attribute types,
Default values,
Labels, descriptions, and other properties.
Syntax of schemas
The root element of the schema is <srcSchema>. It contains the <element> and <attribute>
sub-elements.
38 | © Neolane 2010
The first <element> sub-element coincides with the root of the entity.
Note:
The root element of the entity has the same name as the schema.
The <element> tags define the names of entity elements. <attribute> tags of the schema
define the names of the attributes in the <element> tags which they have been linked to.
Identifying a schema
A data schema is identified by its name and its namespace.
A namespace lets you group a set of schemas by area of interest. For example, the cus
namespace is used for customer-specific configuration (customers).
Warning:
As a standard, the name of the namespace must be concise and must contain only authorized
characters in accordance with XML naming rules.
Identifiers must not begin with numeric characters.
Certain namespaces are reserved for descriptions of the system entities required for the
operation of the Neolane application:
xtk: concerning platform system data,

nl: concerning the overall use of the application,
nms: concerning delivery (recipient, delivery, tracking, etc.),
ncm: concerning content management.
The identification key of a schema is a string built using the namespace and the name separated by
a colon; for example: cus:recipient.
Schema structure
The XML document of a data schema must contain the <srcSchema> root element with the name
and namespace attributes in order to populate the schema name and its namespace.
Let us use the following XML content to illustrate the structure of a data schema:
With its corresponding data schema:
Description
The point of entry of the schema is its main element. It is easy to identify because it has the same
name as the schema, and it should be the child of the root element. The description of the content
begins with this element.
In our example, the main element is represented by the following line:
The elements <attribute> and <element> that follow the main element enable you to define the
locations and names of the data items in the XML structure.
In our sample schema, these are:
40 | © Neolane 2010
The following rules must be adhered to:
Each <element> and <attribute> must be identified by name via the name attribute.
Warning:
The name of the element should be concise, preferably in English, and include only
authorized characters in accordance with XML naming rules.
Only <element> elements can contain <attribute> elements and <element> elements
in the XML structure.
An <attribute> element must have a unique name within an <element>.
The use of <elements> in multi-line data strings is recommended.
Data types
The data type is entered via the type attribute in the <attribute> and <element> elements.
When this attribute is not populated, string is the default data type unless the element contains
child elements. If it does, it is used only to structure the elements hierarchically (<location>
element in our example).
The following data types are supported in schemas:
string: character string. Examples: a first name, a town, etc.
The size can be specified via the length attribute (optional, default value "255").
boolean: Boolean field. Example of possible values: true/false, 0/1, yes/no, etc.
byte, short, long: integers (1 byte, 2 bytes, 4 bytes). Examples: an age, an account
number, a number of points, etc.
double: double-precision floating point number. Examples: a price, a rate, etc.
date, datetime: dates and dates + times. Ecamples: a birth date, a purchase date, etc.
timespan: durations. Example: seniority.
memo: long text fields (multiple lines). Examples: a description, a comment, etc.
uuid: "uniqueidentifier" fields to support a GUID (supported in SQL Server only).
Note:
To contain a uuid field in engines other than SQL Server, the "newuuid()" function must
be added and completed with its default value.
Here is our example schema with the types entered:

Properties
The <elements> and <attributes> elemtns of the data schema can be enriched with various
properties. You can populate a label in order to describe the current element.
Labels and descriptions

The label property lets you enter a brief description.
Note:
The label is associated with the current language of the instance.
Example:
The label can be seen from the Neolane client console input form:
The desc property lets you enter a long description.

The description can be seen from the input form in the status bar of the Neolane client console
main window.
Note:
The description is associated with the current language of the instance.
Example:
Default values
The default property lets you define an expression returning a default value on content creation.
The value must be an expression compliant with XPath language. For more on this, refer to Referencing
with XPath [page 45].
Example:
Current date:
Counter:
In this example, the default value is constructed using the concatenation of a string and calling
the CounterValue function with a free counter name. The number returned is incremented by
one at each insertion.
42 | © Neolane 2010
Note:
In the Neolane client console, the Administration>Counters node is used to manage
counters.
Enumerations
Free enumeration
The userEnum property lets you define a free enumeration to memorize and display the
values entered via this field. The syntax is as follows:
The name given to the enumeration can be chosen freely and shared with other fields.
These values are shown in a drop-down list from the input form:
Note:
In the Neolane client console, the Administration>Enumerations node is used to manage
enumerations.
Set enumeration
The enum property lets you define a fixed enumeration used when the list of possible values
is known in advance.
The enum attribute refers to the definition of an enumeration class populated in the schema
outside the main element.
Enumerations allow the user to select a value from a drop-down list instead of entering the
value in a regular input field:
Example of an enumeration declaration in the data schema:

An enumeration is declared outside the main element via the <enumeration> element.
The enumeration properties are as follows:
baseType: type of data associated with the values,
label: description of the enumeration,
name: name of the enumeration,
default: default value of the enumeration.
The enumeration values are declared in the <value> element with the following attributes:
name: name of the value stored internally,
label: label displayed via the graphical interface.
dbenum enumeration
The dbenum property lets you define an enumeration whose properties are similar to those of
the enum property.
However, the name attribute does not store the value internally, it stores a code which lets you
extend the concerned tables without modifying their schema.
The values are defined via the Administration>Enumerations node.
This enumeration is used for specifying the nature of campaigns, for example.
Example
Here is our example schema with the properties filled in:
44 | © Neolane 2010
Collections
A collection is a list of elements with the same name and the same hierarchical level.
The unbound attribute with the value "true" lets you populate a collection element.
Example: definition of the <group> collection element in the schema.
With projection of the XML content:
Referencing with XPath

The XPath language is used in Neolane to reference an element or attribute belonging to a
data schema.
XPath is a syntax that lets you locate a node in the tree of an XML document.
Elements are designated by their name, and attributes are designated by the name preceded
by the character "@".
Example:
: selects the email,
: selects the "city" attribute under the <location> element
: selects the e-mail address from the parent element of the current element
: selects the "label" attribute that is the child of the first <group>
collection element
: selects the "label" attribute that is the child of the <group>
element and contains the value "test1"

Note:
An additional constraint is added when the path crosses a sub-element. In this case, the following
expression must be placed between brackets:
is not valid; please use
and are equivalent
It is also possible to define complex expressions, such as the following arithmetic operations:
: adds 1 to the content of the gender attribute,
: constructs a string by taking the value of the e-mail address
added to the creation date between parentheses (for the string type, put the constant in quotes).
High-level functions have been added to the expressions in order to enrich the potential of this
language.
You can access the list of available functions via any expression editor in the Neolane client console:
Example:
: returns the current date
: returns the year of the date contained in the "created" attribute.
: returns the domain of the e-mail address.
Building a string via the compute string

A Compute string is an XPath expression used to construct a string representing a record in a table
associated with the schema. Compute string is mainly used in the graphical interface to display
the label of a selected record.
The Compute string is defined via the <compute-string> element under the main element of
the data schema. An expr attribute contains an XPath expression to calculate the display.
Example: compute string of the recipient table.
46 | © Neolane 2010
Result of the computed string for a recipient:
Note:
If the schema does not contain a Compute string, a Compute string is populated by default
with the values of the primary key of the schema.
Database mapping
The SQL mapping of our example schema gives the following XML document:
Description
The root element of the schema is no longer <srcSchema>, but <schema>.
This takes us to another type of document, which is generated automatically from the source
schema, simply referred to as the schema. This schema will be used by the Neolane application.
The SQL names are determined automatically based on element name and type.
The SQL naming rules are as follows:
table: concatenation of the schema namespace and name
In our example, the name of the table is entered via the main element of the schema in
the sqltable attribute:
field: name of the element preceded by a prefix defined according to type ('i' for integer,
'd' for double, 's' for string, 'ts' for dates, etc.)

The field name is entered via the sqlname attribute for each typed <attribute> and
<element>:
Note:
SQL names can be overloaded from the source schema. To do this, populate the "sqltable" or "sqlname"
attributes on the element concerned.
The SQL script to create the table generated from the extended schema is as follows:
The SQL field constraints are as follows:

no null values in numeric and date fields,
numeric fields are initialized to 0.
XML fields
By default, any typed <attribute> and <element> element is mapped onto an SQL field of the
data schema table. You can, however, reference this field in XML instead of SQL, which means that
the data is stored in a memo field ("mData") of the table containing the values of all XML fields. The
storage of these data is an XML document that observes the schema structure.
To populate a field in XML, you must add the xml attribute with the value "true" to the element
concerned.
Example: here are two examples of XML field use.
Multi-line comment field:
Description of data in HTML format:
The "html" type lets you store the HTML content in a CDATA tag and display a special HTML edit
check in the Neolane client interface.
The use of XML fields lets you add fields without needing to modify the physical structure of the
database. Another advantage is that you use less resources (size allocated to SQL fields, limit on the
number of fields per table, etc.).
The main disadvantage is that it is impossible to index or filter an XML field.
48 | © Neolane 2010
Calculated fields
A calculated field is not stored physically in the table; it is a data item that is calculated
dynamically when the query is submitted.
There are two types of calculated fields: SQL calculated fields and XML calculated fields.
1 SQL calculated field: the data is calculated by the database engine from a simple
expression. This type of field is well suited to extracting a substring in order to display the
domain of an e-mail address or to calculate the age by subtracting the date of birth from
the current date.
Note:
SQL expressions can be used directly via the [SQLDATA[expression_sql]] escape
sequence. This syntax must be used with care, however, because the populated SQL
depends on the engine of the current database.
2 XML calculated field: lets you use a more complex expression with XML fields or
conditional tests. The expression is evaluated by the application layer on receipt of the
query data.
The disadvantage of using XML calculated fields is that not all SQL functions of the XPath
expressions are supported.
A calculated field must populate the expr attribute containing the expression to be submitted.
A calculated field is SQL type by default. To declare an XML calculated field, add the xml
attribute (with the value set to "true").
Example:
Returns the e-mail domain:
Calculated field using an SQL expression:
Feature fields
Feature fields are used to extend the data of an existing table, but with remote storage in an
ancillary table.
This type of field can be very useful when the table to be extended has a high volume. The
space allocated to the data is then used on demand.
There are two types of feature fields:
1 simple fields: only one possible value for the feature,
2 multiple choice fields: the feature is associated with a collection element and can
therefore contain several possible values.
To declare a feature field, add the feature attribute (with value "true") to an <element> or
an <attribute> of the schema.

An (optional) date field can be associated with the feature field in order to give the date on which
the value was last modified. To do this, add the featureDate attribute (with value "true") to the
feature element.
An SQL table is created for each feature field. The name of the table is constructed in the following
way: .
This table consists of a field containing the value of the feature (the type declared in the schema),
an internal identifier (numeric value), and a date (optional).
Example:
Simple field:
Note:
The name of the table containing the feature is:
Multiple choice field:
Indexed fields
Indexes let you optimize the performance of the SQL queries used in the application.
An index is declared from the main element of the data schema.
Indexes obey the following rules:

An index can reference one or more fields in the table.
An index can be unique (to avoid duplicates) in all of the fields if the unique attribute contains
the value "true".
The SQL name of the index is determined from the SQL name of the table and the name of the
index.
Note:
As a standard, indexes are the first elements declared from the main element of the schema.
Example:
Adding an index to the e-mail address and city:
50 | © Neolane 2010
Adding a unique index to the "id" name field:
Management of keys
A table must have at least one key for identifying a record in the table.
A key is declared from the main element of the data schema.
Keys obey the following rules:

A key can reference one or more fields in the table.
A key is known as 'primary' (or 'priority') when it is the first in the schema to be populated
or if it contains the internal attribute with the value "true".
A unique index is declared implicitly for each key definition. The creation of an index on
the key can be prevented by adding the noDbIndex attribute with the value "true".

Note:
As a standard, keys are the elements declared from the main element of the schema after indexes
have been defined.
Example:
Adding a key to the e-mail address and city:
The schema generated:
Adding a primary or internal key on the "id" name field:
52 | © Neolane 2010
The extended schema generated:
Auto-incremental key
The primary key of most Neolane tables is a 32-bit long integer auto-generated by the database
engine. The calculation of the key value depends on a sequence (by default, the XtkNewId
SQL function) generating a number that is unique in the entire database. The content of the
key is automatically entered on insertion of the record.
The advantage of an incremental key is that it provides a non-modifiable technical key for the
joins between tables. In addition, this key does not occupy much memory because it uses a
double-byte integer.
From version 4.05 onwards, in the source schema you can specify the name of the sequence
to be used with the pkSequence attribute. If this attribute is not given in the source schema,
the XtkNewId default sequence will be used. The application uses dedicated sequences for
the nms:broadLog and nms:trackingLog schemas (NmsBroadLogId and
NmsTrackingLogId respectively) because these are the tables that contain the most records.

Note:
A sequence referenced in a Neolane schema (NmsTrackingLogId for example) must be associated
to a SQL function that returns the number of IDs in the parameters, separated by commas. This
function must be called GetNewXXXIds, where XXX is the name of the sequence
(GetNewNmsTrackingLogIds for example). View the , or
files provided with the appliation in the directory to recover
the example of a 'NmsTrackingLogId' sequence creation for each database engine.
To declare an auto-incremental key, populate the autopk attribute (with value "true") on the main
element of the data schema.
Example:
Declaring an incremental key in the source schema:
In addition to the definition of the key and its index, a numeric field called "id" has been added to
the extended schema in order to contain the auto-generated primary key.
Important:
A record with a primary key set to 0 is automatically inserted on creation of the table. This record is
used to avoid outer joins, which are not effective on volume tables. By default, all foreign keys are
initialized with value 0 so that a result can always be returned on the join when the data item is not
populated.
Links: relation between tables

A link describes the association between one table and another.
54 | © Neolane 2010
The various types of associations (known as "cardinalities") are as follows:
Cardinality 1-1: one occurrence of the source table can have at most one corresponding
occurrence of the target table.
Cardinality 1-N: one occurrence of the source table can have several corresponding
occurrences of the target table, but one occurrence of the target table can have at most
one corresponding occurrence of the source table.
Cardinality N-N: one occurrence of the source table can have several corresponding
occurrences of the target table, and vice-versa.
A link must be declared in the schema containing the foreign key of the table linked via the
main element:
Links obey the following rules:

The definition of a link is entered on a link-type <element> with the following attributes:
name: name of link from the source table,
target: name of target schema,
label: label of link,
revLink (optional): name of reverse link from the target schema (deduced automatically
by default),
integrity (optional): referential integrity of the occurrence of the source table to the
occurrence of the target table. Possible values are as follows:
define: it is possible to delete the source occurrence if it is no longer referenced
by a target occurrence,
normal: deleting the target occurrence initializes the keys of the link to the source
occurrence (default mode), this type of integrity initializes all foreign keys,
own: deleting the source occurrence leads to the deletion of the target occurrence,
owncopy: the same as own (in case of deletion) or duplicates the occurrences
(in case of duplication),
neutral: does nothing.
revIntegrity (optional): integrity on the target schema (optional, "define" by default),
revCardinality (optional): with value "single" populates cardinality with type 1-1 (1-N
by default).
externalJoin (optional): forces the outer join
revExternalJoin (optional): forces the outer join on the reverse link
A link references one or more fields from the source table to the destination table. The
fields making up the join (<join> element) need not be populated because they are
automatically deduced by default using the internal key of the target schema.
An index is automatically added to the foreign key of the link in the extended schema.
A link consists of two half-links, where the first is declared from the source schema and
the second is created automatically in the extended schema of the target schema.

A join can be an outer join if the externalJoin attribute is added, with the value "true" (not
supported in PostgreSQL).
Note:
As a standard, links are the elements declared at the end of the schema.
Example 1
1-N relation to the "cus:company" schema table:
The extended schema generated:
The link definition is supplemented by the fields making up the join, i.e. the primary key with its
XPath ("@id") in the destination schema, and the foreign key with its XPath ("@company-id") in the
schema.
The foreign key is added automatically in an element that uses the same characteristics as the
associated field in the destination table, with the following naming convention: name of target schema
followed by name of associated field ("company-id" in our example).
Extended schema of the target ("cus:company"):
56 | © Neolane 2010
A reverse link to the "cus:recipient" table was added with the following parameters:
name: automatically deduced from the name of the source schema (can be forced with
the "revLink" attribute in the link definition on the source schema)
revLink: name of reverse link
target: key of linked schema ("cus:recipient" schema)
unbound: the link is declared as a collection element for a 1-N cardinality (by default)
integrity: "define" by default (can be forced with the "revIntegrity" attribute in the link
definition on the source schema).
Example 2
In this example, we will declare a link towards the "nms:address" schema table. The join is
an outer join and is populated explicitly with the recipient's e-mail address and the "@address"
field of the linked table ("nms:address").
Example 3
1-1 relation to the "cus:extension" schema table:
Example 4
Link to a folder ("xtk:folder" schema):
The default value returns the identifier of the first eligible parameter type file entered in the
"DefaultFolder('nmsFolder')" function.

Example 5
In this example, we wish to create a key on a link ("company" to "cus:company" schema) with the
xlink attribute and a field of the ("email") table:
The definition of the "companyEmail" name key was extended with the foreign key of the "company"
link. This key generates a unique index on both fields.
58 | © Neolane 2010
Editing schemas
Presentation
To edit, create and configure the schemas, click the Administration>Configuration>Data
schemas node of the Neolane client console.
The edit field shows the XML content of the source schema:
Note:
The "Name" edit control lets you enter the schema key made up of the name and namespace.
The "name" and "namespace" attributes of the root element of the schema are automatically
updated in the XML editing zone of the schema.

The preview automatically generates the extended schema:
Note:
When the source schema is saved, generation of the extended schema is automatically launched.
Example: creating a contract table

In the following example, we want to create a new table for contracts in the database model of the
Neolane database. This table lets you store first and last names and email addresses of holders and
co-holders, for each contract.
To do this, you need to create the schema of the table and update the database structure to generate
the corresponding table. Apply the following stages:
1 Edit the Administration>Configurations>Data schemas node of the Neolane tree and click
New.
60 | © Neolane 2010
2 Choose the Create a new table in the data model option and click Next.
3 Specify a name for the table and a namespace.

Note:
By default, schemas created by users are stored in the 'cus' namespace. For more on this, refer
to Identifying a schema [page 39].
4 Create the content of the table. We recommend using the entry wizard to make sure no settings
are missing. To do this, click the Insert button and choose the type of setting to be added.
5 Define the settings for the contract table:
Add the type of contract and place an index on the contract number.
62 | © Neolane 2010
6 Save the schema to generate the structure:
7 Update the database structure to create the table which the schema will be linked to. For more
on this, refer to Updating the physical structure of the database [page 69].
Schema of an existing table or a view
Presentation
When the application needs to access the data of an existing table, an SQL view, or data from a
remote database, create its schema in Neolane with the following data:
Name of table: enter the name of the table (with its alias when a dblink is used) with the "sqltable"
attribute,
schema key: reference the reconciliation field(s),
indexes: used to generate queries,
The fields and their location in the XML structure: fill in only the fields used in the application,
links: if there are joins with the other tables of the base.
Implementation
To create the corresponding schema, apply the following stages:
64 | © Neolane 2010
1 Edit the Administration>Configurations>Data schemas of the Neolane tree and click
New.
2 Select the Access data from an existing table or an SQL view option and click Next.
3 Choose the table or the existing view:

4 Adapt the schema content to suit your needs.
Important:
The schema must be populated with the view="true" attribute on the <srcSchema> root
element in order not to generate a table creation SQL script.
Example:
Accessing an external database

Purchasing the Federated Data Access option give you access to the data stored in an external
database.
To do this, apply the following stages:
1 Edit the Administration>Configurations>Data schemas node of the Neolane tree and click
New.
66 | © Neolane 2010
2 Select the Access external data option and click Next.
3 Select the external account and choose the table you want.

Note:
For more information on configuring external accounts, refer to the Advanced user's guide.
Click the Next button to launch schema generation.

4 Check and make any necessary alterations to the new schema settings and click Save.
Extending an existing schema
Warning:
Some out-of-the-box schemas must not be extended: mainly those for which the following settings
are defined:
and .
The following schemas must not be extended: , ,
, , , , , ,
, , , , ,
, , , , , ,
, , , , .
This list is not exhaustive.
There are two methods for extending an existing schema:

1 Modifying the source schema directly.
2 Creating another schema with the same name but a different namespace. The advantage is that
you can extend a table without needing to modify the original schema.
68 | © Neolane 2010
The root element of the schema must contain the extendedSchema attribute with the
name of the schema to be extended as its value.
An extension schema does not have its own schema: the schema generated from the
source schema will be filled in with the fields of the extension schema.
Example: extension of the nms:recipient schema.
The nms:recipient extended schema is filled in with the field populated in the extension
schema:
The dependingSchemas attribute on the root element of the schema references the
dependences on the extension schemas.
The belongsTo attribute on the field fills in the schema where it is declared.
Important:
Do not modify the standard schemas of the application, but rather the schema extension
mechanism. Otherwise, modified schemas will not be updated at the time of future upgrades
of the application. This can lead to malfunctions in the use of Neolane.
Updating the physical structure of the database

To apply the modifications made to the schemas, launch the database update wizard. This
wizard is accessible via Tools>Advanced>Update database structure. It checks whether

the physical structure of the database matches its logical description and executes the SQL update
scripts.
The modules in the database are automatically populated and activated.
The Add stored procedures and Import initialization data options are used to launch the initial
SQL scripts and the data packages executed when the database is created.
You can import a set of data from an external data package. To do this, select Import a package
and enter the XML file of the package.
70 | © Neolane 2010
Follow the steps and view the database update SQL script:
Note:
This is in an editing field and can be modified in order to delete or add SQL code.
Next, launch the database update:

New field wizard
A wizard accessible via Tools>Advanced>Add new fields lets you add one or more fields to a
table in the database.
Validating the wizard updates the extension schema of the table to be extended and launches the
SQL script to modify the physical structure of the database.
This assistant has the advantage of quickly adding a field without needing to know the structure of
a data schema.
The main disadvantage is the limitation of the data and the properties to be extended.
The wizard screens contain the following steps:
1 The first page lets you enter the name of the schema to be extended and the namespace of the
extension schema where the modifications will be saved:
72 | © Neolane 2010
2 The next page lets you enter the properties of the field to be added.
3 To confirm the changes, click the Finish button.

An extension file, called "cus:recipient" in our example, is automatically created and the
corresponding SQL script is executed:
Note:
By default, the added fields are declared with the property user (with the value "true"). This
lets you display and edit the field in the input form of the extended schema using a
"treeEdit"-type control (refer to Input forms [page 83]).

Structure of a schema
The structure of a data schema is shown in the form of a tree structure. To view it graphically in the
Neolane client console, select the targeted schema and click the Structure sub-tab.
As a standard, the fields are displayed first (Active, Activated, etc.) and in alphabetical order. The
structuring elements come next (Postal address, Location), and finally the links (E-mail information,
Folder, etc.).
Primary keys are identified by a red key, and foreign keys are identified by a yellow key.
Links are distinguished graphically depending on whether they belong to the table. Those that start
from the table, i.e. that have the foreign key in the table, are displayed first (E-mail information,
Folder, Country). "Reverse" collection links (Subscription, Orders, etc.) are displayed at the end.
Regenerating all schemas

To regenerate all the schemas and solve certain dependency problems in the reverse links, launch
the following command from the Neolane application server:
You must then reboot the Neolane application server and reconnect to the client console.
74 | © Neolane 2010
Examples
Extending a table
To extend the nms:recipient schema recipient table, apply the following procedure:
1 Create the extension schema (cus:extension) using the following data:
In this example, an indexed field (fidelity) is added, and the location element (which
already existed in the nms:recipient schema) is supplemented with an enumerated field
(area).
Warning:
Remember to add the extendedSchema attribute to reference the extension schema.
2 Check that the extended schema is the nms:recipient schema and that the additional
data is present:

The SQL script generated from the database update wizard is as follows:
Linked collection table

This section describes how to create an order table linked to the recipient table with cardinality 1-N.
Order table source schema:
The table type is autopk in order to create an auto-generated primary key to be used by the join
of the link to the recipient table.
Schema generated:
76 | © Neolane 2010
The table creation SQL script is as follows:
Note:
The SQL command INSERT INTO at the end of the script lets you insert an identifier record
set to 0 in order to simulate outer joins.
Extension table
An extension table lets you extend the content of an existing table in a linked table of cardinality
1-1.
The purpose of an extension table is to avoid limitations on the number of fields supported in
a table, or to optimize the space occupied by the data, which is consumed on demand.
Note:
This type of table can be replaced by feature fields. For further information, refer to Feature
fields [page 49].
Creating the extension table schema (cus:feature):

Creating an extension schema on the recipient table to add the link of cardinality 1-1:
Note:
The definition of the link between the recipient table and the extension table must be populated from
the schema containing the foreign key.
The SQL script for creating the extension table is as follows:
The recipient table SQL update script is as follows:
Overflow table
An overflow table is an extension table (cardinality 1-1), but the declaration of the link to the table
to be extended is populated in the schema of the overflow table.
The overflow table contains the foreign key to the table to be extended. The table to be extended
is therefore not modified. The relation between the two tables is the value of the primary key of the
table to be extended.
Creating the overflow table schema (cus:overflow):
78 | © Neolane 2010
Note:
The primary key of the overflow table is the link to the table to be extended ("nms:recipient"
schema in our example).
Relationship table
A relationship table lets you link two tables with cardinality N-N. This table contains only the
foreign keys of the tables to be linked.
Example of a relationship table between groups (nms:group) and recipients (nms:recipient).
Source schema of the relationship table:
The schema generated is as follows:

Seed list management

For direct-mail campaigns, you have the possibility of inserting control addresses or "seed addresses"
in the output file.
The nms:seedMember schema and the form with the same name that are provided as standard
are intended to be extended at the implementation level in order to reference the necessary fields.
The schema definition contains comments explaining how it works.
Using an external table

If the campaigns table is an external table, you must make additional configurations. The
nms:seedmember schema must be extended. You must add a new element at the root of the
seedMember elements with the following parameters:
80 | © Neolane 2010
This element must contain the fields required to export the campaigns. These fields should
have the same name as the corresponding fields in the custom schema. For example, if the
schema is company:customer, the seedMember schema should be extended as follows:
The seedMember form must be modified accordingly.

If all attributes of the control address aren't filled in, they will be populated automatically during
file writing, with data that already exists in the file.
Expression placeholders
You may need to export data that is not stored in a single field but calculated at export time.
Such data cannot be calculated for the seed records, however a placeholder for the expression
can be used. Add a new field in the seedMember schema and then populate the seeds with
a fixed value.
Example of implementation:
When exporting expressions, the application generates aliases that must be replaced. The
export model must be changed and the column containing the expression changed to reference
the field:
and
and

An alias has been automatically generated for the expression. This alias must be changed in order
to reference the seedMember field:
and
82 | © Neolane 2010
CHAPTER 3
Input forms
Table of Contents
Identifying a form . . . . . . . . . . . . . . . . . . . . . . . . 83
Form structure . . . . . . . . . . . . . . . . . . . . . . . . . 84
Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Containers . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Editing a link . . . . . . . . . . . . . . . . . . . . . . . . . 89
List of links . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Memory list controls . . . . . . . . . . . . . . . . . . . . . . 93
Non-editable fields . . . . . . . . . . . . . . . . . . . . . . . 95
Radio button . . . . . . . . . . . . . . . . . . . . . . . . . 95
Checkbox . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Navigation hierarchy edit . . . . . . . . . . . . . . . . . . . . . 96
Expression field . . . . . . . . . . . . . . . . . . . . . . . . 96
Context of forms . . . . . . . . . . . . . . . . . . . . . . . . 96
Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Editing forms . . . . . . . . . . . . . . . . . . . . . . . . . . 99
An input form lets you edit an instance associated with a data schema from the Neolane client
console.
Identifying a form
An input form is identified by its name and namespace.
Neolane v5.1 - Configuration Guide - Input forms | 83

The identification key of a form is a string made up of the namespace and the name separated by a
colon (':') (for example: "cus:contact").
Form structure
The description of a form is a structured XML document that observes the grammar of the form
schema xtk:form.
The XML document of the input form must contain the <form> root element with the name and
namespace attributes to populate the form name and namespace.
By default, a form is associated with the data schema with the same name and namespace. To
associate a form with a different name, set the entity-schema attribute of the <form> element to
the name of the schema key.
To illustrate the structure of an input form, let us describe an interface using the "cus:recipient"
example schema:
The input form based on the example schema:
The description of the edit controls starts from the <form> root element.
84 | © Neolane 2010
An edit control is entered in an <input> element with the xpath attribute containing the
path of the field in its schema.
The edit control automatically adapts to the corresponding data type and uses the label defined
in the schema.
Note:
You can overload the label defined in its data schema by adding the label attribute to the
<input> element:
By default, each field is displayed on a single line and occupies all available space depending
on the type of data.
Formatting
The layout of the controls looks like the layout used in HTML tables, with the possibility of
dividing a control into several columns, interlacing elements, or specifying the occupation of
available space. Remember, however, that formatting only lets you divide the area up by
proportions; you cannot specify fixed dimensions for an object.
To display the controls of the above example in two columns:
The <container> element with the colcount attribute lets you force the display of child
controls onto two columns.
The colspan attribute on a control extends the control by the number of columns entered in
its value:

By populating the type="frame" attribute, the container adds a frame around the child controls
with the label contained in the label attribute:
A <static> element can be used to format the input form:
The <static> tag with the separator type lets you add a separator bar with a label contained in
the label attribute.
A help text was added using the <static> tag with a help type. The content of the text is entered
in the label attribute.
Containers
Containers let you group a set of controls. They are represented by the <container> element. They
were used above to format controls over several columns.
The xpath attribute on a <container> lets you simplify the referencing of child controls. The
referencing of controls is then relative to the parent <container> parent.
Example of a container without "xpath":
86 | © Neolane 2010
Example with the addition of "xpath" to the element called "location":
Types of container
Containers are used to construct complex controls using a set of fields formatted in pages.
Tab container
A tab container formats data in pages that are accessible from tabs.
The main container is defined by the type="notebook" attribute. Tabs are declared in the
child containers, and the label of the tabs is populated from the label attribute.
Note:
A style="down|up(by default)" feature forces the vertical positioning of tab labels below
or above the control. This feature is optional.

Icon list
This container displays a vertical icon bar that lets you select the pages to be displayed.
The main container is defined by the type="iconbox" attribute. The pages associated with the
icons are declared in the child containers. The label of the icons is populated from the label attribute.
The icon of a page is populated from the img="<image>" attribute, where <image> is the name
of the image corresponding to its key made up of the name and namespace (e.g.,
"xtk:properties.png").
The images are available from the Administration > Configuration > Images node.
Visibility container
You can mask a set of controls via a dynamic condition.
This example illustrates the visibility of controls on the value of the "Gender" field:
A visibility container is defined by the attribute type="visibleGroup". The visibleIf attribute

contains the visibility condition.
Examples of condition syntax:
: tests equality on string-type
data. The comparison value must be in quotes.
: condition on a numeric value.
: test on Boolean fields.
88 | © Neolane 2010
Enabling container
This container lets you enable or disable a set of data from a dynamic condition. Disabling a
control prevents it from being edited. The following example illustrates the enabling of controls
from the value of the "Gender" field:
An enabling container is defined by the type="enabledGroup" attribute. The enabledIf

attribute contains the activation condition.
Editing a link
Remember that a link is declared in the data schema as follows:
The edit control of the link in its input form is as follows:
Target selection is accessible via the edit field. Entry is assisted by type-ahead so that a target
element can easily be found from the first few characters entered. The search is then based
on the Compute string defined in the targeted schema. If the schema does not exist after
validation in the control, a confirmation message of on-the-fly target creation is displayed. The
confirmation creates a new record in the target table and associates it with the link.
A drop-down list is used to select a target element from the list of records already created.
The Modify the link (folder) icon launches a selection form with the list of targeted elements
and a filter zone:

The Edit link (magnifier) icon launches the edit form of the linked element. The form used is deduced
by default on the key of the targeted schema. The form attribute lets you force the name of the edit
form (e.g. "cus:company2").
You can restrict the choice of target elements by adding the <sysFilter> element from the link
definition in the input form:
You can also sort the list with the <orderBy> element:
Control properties
noAutoComplete: disables type-ahead (with the value "true")
createMode: creates the link on the fly if it does not exist. Possible values are:
none: disables creation. An error message is displayed if the link does not exist
inline: creates the link with the content in the edit field
edition: displays the edit form on the link. When the form is validated, the data is saved
(default mode)
noZoom: no edit form on the link (with the value "true")
form: overloads the edit form of the targeted element
List of links
A link entered in the data schema as a collection element (unbound "true") must go through a list in
order to view all the elements associated with it.
The principle consists in displaying the list of linked elements with optimized data loading (downloading
by data batch, execution of the list only if it is visible).
Example of a collection link in a schema:
The list in its input form:
90 | © Neolane 2010
List control is defined by the type="linklist" attribute. The list path must refer to the collection
link.
The columns are declared via the <input> elements of the list. The xpath attribute refers
to the path of the field in the target schema.
A toolbar with a label (defined on the link in the schema) is automatically placed above the
list.
The list can be filtered via the Filters button and configured to add and sort the columns.
The Add and Delete buttons let you add and delete collection elements on the link. By default,
adding an element launches the edit form of the target schema.
The Detail button is automatically added when the zoom="true" attribute is completed on
the <input> tag of the list: it lets you launch the edit form of the selected line.
Filtering and sorting can be applied when the list is being loaded:
Relationship table
A relationship table lets you link two tables with N-N cardinality. The relationship table contains
only the links to the two tables.
Adding an element to the list should therefore let you complete a list from one of the two links
in the relationship table.
Example of a relationship table in a schema:

For our example, we start with the input form of the "cus:recipient" schema. The list must display
the associations with subscriptions to services and must allow you to add a subscription by selecting
an existing service.
The xpathChoiceTarget attribute lets you launch a selection form from the link entered. Creating
the relationship table record will automatically update the link to the current recipient and the selected
service.
Note:
The xpathEditTarget attribute lets you force editing of the selected line on the link entered.
List properties
noToolbar: hides the toolbar (with value "true")
toolbarCaption: overloads the toolbar label
toolbarAlign: modifies the vertical or horizontal geometry of the toolbar (possible values:
"vertical"|"horizontal")
img: displays the image associated with the list
zoom: adds the Zoom button to edit the targeted element
xpathEditTarget: sets editing on the link entered
xpathChoiceTarget: for addition, launches the selection form on the link entered
92 | © Neolane 2010
Memory list controls
Memory lists let you edit the collection elements using list data preloading. This list cannot be
filtered or configured.
These lists are used on XML mapped collection elements or on low-volume links.
Column list
This control displays an editable column list with a toolbar containing Add and Delete buttons.
The list control must be filled in with the type="list" attribute, and the path of the list must
refer to the collection element.
The columns are declared in the child <input> tags of the list. Column label and size can be
forced with the label and colSize attributes.
Note:
Sort-order arrows are added automatically when the ordered="true" attribute is added to
the collection element in the data schema.
The toolbar buttons can be aligned horizontally:

The toolbarCaption attribute forces the horizontal alignment of the toolbar and enters the title
above the list.
Zoom in a list
Insertion and editing of the data in a list can be entered in a separate edit form.
The edit form is completed from the <form> element under list definition. Its structure is identical
to that of an input form.
The Detail button is added automatically when the zoom="true" attribute is completed on the
<input> tag of the list. This attribute lets you launch the edit form of the selected line.
Note:
Adding the zoomOnAdd="true" attribute forces the edit form to be called on insertion of a list
element.
Properties of the list

noToolbar: hides the toolbar (with value "true")
toolbarCaption: overloads the toolbar label
toolbarAlign: modifies the positioning of the toolbar (possible values: "vertical"|"horizontal")
img: displays the image associated with the list
94 | © Neolane 2010
zoom: adds the Zoom button to edit the targeted element
zoomOnAdd: launches the edit form on the addition
xpathChoiceTarget: for addition, launches the selection form on the completed link
Non-editable fields
To display a field and prevent it from being edited, use the <value> tag or complete the
readOnly="true" attribute on the <input> tag.
Example on the "Gender" field:
Radio button
A radio button lets you choose from several options. The <input> tags are used to list the
possible options, and the checkedValue attribute specifies the value associated with the
choice.
Example on the "Gender" field:
Checkbox
A checkbox reflects a Boolean state (selected or not). By default, this control is used by
"Boolean" (true/false) fields. A variable taking a default value of 0 or 1 can be associated with
this button. This value can be overloaded via the checkValue attributes.

Navigation hierarchy edit
This control builds a tree on a set of fields to be edited.
The controls to be edited are grouped in a <container> entered under the <input> tag of the
tree control:
Expression field
An expression field updates a field dynamically from an expression; the <input> tag is used with
an xpath attribute to enter the path of the field to be updated and an expr attribute containing the
update expression.
Context of forms
The execution of an input form initializes an XML document containing the data of the entity being
edited. This document represents the context of the form, and can be used as a workspace.
Updating the context

To modify the context of the form, use the tag,
where <field> is the destination field, and <value> is the update expression or value.
Examples of use of the <set> tag:
: positions the 'Test' value at temporary
location /tmp/@test1
: updates the entity on the "lastName" attribute
with the 'Test' value
96 | © Neolane 2010
: sets the value of the "boolean1" field to
"true"
: updates with the content of the
"lastName" attribute
The context of the form can be updated when initializing and closing the form via the <enter>
and <leave> tags.
Note:
The <enter> and <leave> tags can be used on the <container> of pages ("notebook" and
"iconbox" types).
Expression language
A macro-language can be used in form definition in order to perform conditional tests.
The tag executes the instructions specified under the tag if
the expression is verified:
The tag combined with the tag prevents

validation of the form and displays an error message if the condition is not satisfied:
Wizards
A wizard guides you through a set of data entry steps in the form of pages. The data entered
is saved when you validate the form.
A wizard has the following structure:

The presence of the type="wizard" attribute on the <form> element lets you define the wizard
mode in the construction of the form.
The pages are completed from <container> elements, which are children of the <form> element.
The <container> element of a page is populated with the title attributes for the title and desc to
display the description under the page title.
The Previous and Next buttons are automatically added to allow browsing between pages.
The Finish button saves the data entered and closes the form.
SOAP methods
SOAP method execution can be launched from a populated <leave> tag at the end of a page.
The <soapCall> tag contains the call for the method with the following input parameters:
The name of the service and its implementation schema are entered via the name and service
attributes of the <soapCall> tag.
The input parameters are described on the <param> elements under the <soapCall> tag.
The parameter type must be specified via the type attribute. The possible types are as follows:
string: character string
boolean: Boolean
byte: 8-bit integer
98 | © Neolane 2010
short: 16-bit integer
long: 32-bit integer
short: 16-bit integer
double: double-precision floating point number
DOMElement: element-type node
The exprIn attribute contains the location of the data to be passed as a parameter.
Example:
Editing forms
The input form creation and configuration screen is accessible from the Administration >
Configuration > input forms folder of the Neolane client console:

The editing zone lets you enter the XML content of the input form:
The preview generates a display of the input form:
100 | © Neolane 2010

CHAPTER 4
API
Table of Contents
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Definition of Neolane APIs . . . . . . . . . . . . . . . . . . . . 102
Using Neolane APIs . . . . . . . . . . . . . . . . . . . . . . 102
SOAP calls . . . . . . . . . . . . . . . . . . . . . . . . . 103
Data oriented API . . . . . . . . . . . . . . . . . . . . . . . . 106
Overview of the datamodel . . . . . . . . . . . . . . . . . . . . 106
Description of the model . . . . . . . . . . . . . . . . . . . . 106
Query and Writer . . . . . . . . . . . . . . . . . . . . . . . 106
Example . . . . . . . . . . . . . . . . . . . . . . . . . . 107
ExecuteQuery (xtk:queryDef) . . . . . . . . . . . . . . . . . . . 107
Write / WriteCollection (xtk:session) . . . . . . . . . . . . . . . . 116
Business oriented APIs . . . . . . . . . . . . . . . . . . . . . . 119
JavaScript example of the insertion of a resource in Neolane . . . . . . . . 120
Subscribe (nms:subscription) . . . . . . . . . . . . . . . . . . . 120
Unsubscribe (nms:subscription) . . . . . . . . . . . . . . . . . . 122
SubmitDelivery (nms:delivery) . . . . . . . . . . . . . . . . . . 123
Implementing SOAP methods in JavaScript . . . . . . . . . . . . . . . 124
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 124
Definition of a method library . . . . . . . . . . . . . . . . . . . 124
Current limitations . . . . . . . . . . . . . . . . . . . . . . . 126
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Use SOAP methods in JavaScript . . . . . . . . . . . . . . . . . . . 126
Static methods . . . . . . . . . . . . . . . . . . . . . . . . 127
Non-static methods . . . . . . . . . . . . . . . . . . . . . . 127
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Neolane v5.1 - Configuration Guide - API | 101

Web service calls . . . . . . . . . . . . . . . . . . . . . . . . . . 129
General information . . . . . . . . . . . . . . . . . . . . . . . . 129
Definition of Web services . . . . . . . . . . . . . . . . . . . . . . 129
Web service description: WSDL . . . . . . . . . . . . . . . . . . . . 130
Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Safety: authentication mechanism . . . . . . . . . . . . . . . . . . . 132
Examples of programs in various languages . . . . . . . . . . . . . . . . 134
Appendix 1 - Examples . . . . . . . . . . . . . . . . . . . . . . . . 138
PHP examples . . . . . . . . . . . . . . . . . . . . . . . . . . 138
C# example . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
JSP example . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Appendix 2 - Using SOAP to collect data from a profile . . . . . . . . . . . . . 147
Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Using data from the profile . . . . . . . . . . . . . . . . . . . . . . 149
Presentation
Definition of Neolane APIs

The Neolane application server was designed for openness and easy integration with increasingly
diverse and complex company information systems.
Neolane APIs are used in JavaScript within the application and in SOAP outside of it. They make up
a library of generic functions that can be enriched. For further information, refer to Implementing
SOAP methods in JavaScript [page 124].
Using Neolane APIs

Neolane uses several types of APIs:
Generic data acces APIs for querying the datamodel data. Refer to Data oriented API [page 106].
Business specific APIs that let you act on each object: deliveries, workflows, subscriptions, etc.
Refer to Business oriented APIs [page 119].
In order to develop APIs and interact with Neolane, you need to be familiar with your datamodel.
Neolane lets you generate a complete description of the base. Refer to Description of the model
[page 106].
Warning:
The use of APIs in Neolane is reseved for power users and should be carried out with care. For
optimized use, we recommend that you restrict the number of API calls to make sure they operate
efficiently. We also encourage batch use. the max. number of calls per second is 10, unless your
architecture was designed for more.
102 | © Neolane 2010

SOAP calls
The SOAP protocol lets you invoke API methods, via the rich client, third-party applications
using webservices, or JSP using these methods natively.
Figure 4.1. Neolane architecture
The structure of a SOAP message is as follows:

an envelope which defines the structure of the message,
an optional header,
a body containing the information about the call and the response,
error management that defines the error condition.
Example of a SOAP message on the "ExecuteQuery" method

In this example, a SOAP query invokes the "ExecuteQuery" method, which takes a character
string as a parameter for authentication (session token) and an XML content for the description
of the query to be executed.
For further information, refer to ExecuteQuery (xtk:queryDef) [page 107].
Note:
The WSDL description of this service is completed in the example shown here: Web service
description: WSDL [page 130].
SOAP query

The <SOAP-ENV:Envelope> element is the first element of the message representing the SOAP
envelope.
The <SOAP-ENV:Body> element is the first child element of the envelope. It contains the description
of the message, i.e. the content of the query or the response.
The method to be invoked is entered in the <ExecuteQuery> element from the body of the SOAP
message.
In SOAP, the parameters are recognized by order of appearance. The first parameter,
<__sessiontoken>, takes the authentication chain, the second parameter is the XML description of
the query from the <queryDef> element.
SOAP response
The result of the query is entered from the <pdomOutput> element.
Error management
Example SOAP error response:
104 | © Neolane 2010

The <SOAP-ENV:Fault> element in the body of the SOAP message is used to convey the error
signals arising during the processing of the Web service. This is composed of the following
sub-elements:
<faultcode>: indicates the type of error. The error types are:
"VersionMismatch" in the event of incompatibility with the SOAP version used,
"MustUnderstand" in the event of a problem in the message header,
"Client" in the event that the client is missing some information,
"Server" in the event that the server has a problem executing the processing.
<faultstring>: message describing the error
<detail>: long error message
The success or failure of the service invocation is identified when the <faultcode> element is
verified.
Important:
All Neolane Web services handle errors. It is therefore strongly recommended to test each call
in order to handle returned errors.
Example of error handling in C#:
URL of Web service server (or EndPoint)

To submit the Web service, the Neolane server that implements the corresponding service
method must be contacted.
The server URL is as follows:
http://<server>/nl/jsp/soaprouter.jsp
With <server> the Neolane application server (nlserver web).

Data oriented API
Data oriented APIs let you address the entire datamodel.
Overview of the datamodel

Neolane does not offer a dedicated read API per entity (no getRecipient or getDelivery function, etc.).
Use the QUERY & WRITER data read and modification methods to access the data of the model.
Neolane lets you manage collections: queries enable you to recover a set of information collected
throughout the base. Unlike access in SQL mode, Neolane APIs return an XML tree instead of data
columns. Neolane thus creates composite documents with all the collected data.
This operating mode does not offer one-to-one mapping between the attributes and elements of the
XML documents and the columns of the tables in the database.
XML documents are stored in CLOB fields of the base.
Description of the model

You must be familiar with the Neolane data model.
For a presentation of the data model, refer to Neolane data model [page 9].
In order to generate its structure, use the following process:
1 Import the datakit\nms\fra\package\optional\dbdBuilder.xml package.
2 Launch the following command on your Neolane instance:
The file is generated in the Neolane installation folder and contains

a description of the Neolane tables. This file can be edited with Open Office and/or converted to
PDF format if necessary.
Query and Writer

ExecuteQuery
For columns and conditions, you can use Queries.
This lets you isolate the underlying SQL. The query language does not depend on the underlying
engine: some functions will be re-mapped, which may generate several SELECT SQL orders.
For more on this, refer to Example on the "ExecuteQuery" method of the "xtk:queryDef" schema
[page 130].
The ExecuteQuery method is presented in ExecuteQuery (xtk:queryDef) [page 107].
An example is available in Appendix 2 - Using SOAP to collect data from a profile [page 147].
Write
Write commands let you write simple or complex documents, with entries in one or more tables of
the base.
106 | © Neolane 2010

Transactional APIs let you manage reconciliations via the updateOrInsert command: one
command lets you create or update data. You can also configure modification merging (merge):
this operating mode lets you authorize partial updates.
The XML structure offers a logical view of the data and lets you sidestep the physical structure
of the SQL table.
The Write method is presented in Write / WriteCollection (xtk:session) [page 116].
Example
Example in JavaScript of Writer use for inserting a recipient in the database.
ExecuteQuery (xtk:queryDef)
This method lets you perform queries from data associated with a schema. It takes an
authentication string (login/password or session token) and an XML document describing the
query to be submitted as parameters. The return parameter is an XML document containing
the result of the query in the format of the schema to which the query refers.
Definition of the "ExecuteQuery" method in the "xtk:queryDef" schema:
Note:
This is a "const" method. The input parameters are included in an XML document in the format
of the "xtk:queryDef" schema.
Format of the XML document of the input query

The structure of the XML document of the query is described in the "xtk:queryDef " schema.
This document describes the clauses of a SQL query: "select", "where", "order by", "group
by", "having".

A query must reference a start schema from the schema attribute.
The type of operation desired is entered in the operation attribute and contains one of the following
values:
get: retrieves a record from the table and returns an error if the data does not exist,
getIfExists: retrieves a record from the table and returns an empty document if the data does
not exist,
select: creates a cursor to return several records and returns an empty document if there is no
data,
count: returns a data count.
The XPath syntax is used to locate data based on the input schema. For further information about
XPaths, refer to Extending schemas [page 37].
Example with the "get" operation

Retrieves the last name and first name of a recipient ("nms:recipient" schema) with a filter on the
e-mail.
108 | © Neolane 2010

Example with the "select" operation
Returns the list of recipients filtered on a folder and the e-mail domain with a sort in descending
order on date of birth.
Expressions can be simple fields or complex expressions such as arithmetic operations or the
concatenation of strings.
It is possible to enter SQL code instead of XPath expressions using the sql attribute.
To limit the number of records to be returned, add the lineCount attribute to the <queryDef>
element.
To limit the number of records returned by the query to 100:
To retrieve the next 100 records, run the same query again, adding the startLine attribute.
Example with the "count" operation

To count the number of records on a query:

Note:
Again we use the condition from the previous example. The <select> and <orderBy> clauses are
not used.
Data grouping
To retrieve e-mail addresses referenced more than once:
The query can be simplified by adding the groupBy attribute directly to the field to be grouped:
Note:
It is no longer necessary to populate the <groupBy> element.
Bracketing in conditions
Here are two examples of bracketing on the same condition.
The simple version in a single expression:
The structured version with <condition> elements:
110 | © Neolane 2010

It is possible to replace the 'OR' operator with the 'IN' operation when several conditions apply
to the same field:
This syntax simplifies the query when more than two data are used in the condition.
Examples on links
Links 1-1 or N1: when the table has the foreign key (the link starts from the table), the
fields of the linked table can be filtered or retrieved directly.
Example of a filter on the folder label:
To retrieve the fields of the folder from the "nms:recipient" schema:
Collection links (1N): the filtering on the fields of a collection table must be performed via
the EXISTS or NOT EXISTS operator.
To filter the recipients who have subscribed to the 'Newsletter' information service:
Direct retrieval of the fields of a collection link from the <select> clause is not recommended
because the query returns a cardinal product. It is used only when the linked table contains
only one record (example <node expr="").
Example on the "subscription" collection link:

It is possible to retrieve a sub-list containing the elements of a collection link in the <select>
clause. The XPaths of the referenced fields are contextual from the collection element.
The filtering (<orderBy>) and restriction (<where>) elements can be added to the collection
element.
In this example, for each recipient the query returns the e-mail and list of information services
to which the recipient subscribes:
Binding the parameters of the "where" clause:

The binding of parameters lets the engine set the values of the parameters used in the query. This
is very useful, since the engine is in charge of the escaping of values, and there is the additional
benefit of a cache for the parameters to be retrieved.
When a query is constructed, the "bound" values are replaced by a character (? in ODBC, #[index]
in postgres...) in the body of the SQL query.
To avoid binding a parameter, the "noSqlBind" attribute must be populated with the value 'true'.
Query-building tip:
To help with the syntax of a query, you can write the query using the generic query editor in the
Neolane client console (Tools/ Generic query editor... menu). To do this:
112 | © Neolane 2010

1 Select the data to be retrieved:
2 Define the filter condition:

3 Execute the query and press CTRL+F4 to view the query source code.
Output document format

The return parameter is an XML document in the format of the schema associated with the query.
Example of a return from the "nms:recipient" schema on a "get" operation:
On a "select" operation, the document returned is an enumeration of elements:
Example of a document returned for "count" type operation:
114 | © Neolane 2010

Alias
An alias lets you modify the location of data in the output document. The alias attribute must
specify an XPath on the corresponding field.
Returns:
Instead of:
Example of SOAP messages

Query:
Response:

Write / WriteCollection (xtk:session)
These services are used to insert, update, or delete an entity ("Write" method) or a collection of
entities ("WriteCollection" method).
The entities to be updated are associated with a data schema. The input parameters are an
authentication string (login/password or session token) and an XML document containing the data
to be updated.
This document is supplemented by instructions for configuring the write procedures.
The call does not return any data, except errors.
Definition of the "Write" and "WriteCollection" methods in the "xtk:session" schema:
Note:
This is a "static" method. The input parameters are included in an XML document in the format of
the schema to be updated.
Operating principle
Data reconciliation operates based on the definition of the keys entered in the associated schema.
The write procedure looks for the first eligible key based on the data entered in the input document.
The entity is inserted or updated based on its existence in the database.
The key of the schema of the entity to be updated is completed based on the xtkschema attribute.
116 | © Neolane 2010

The reconciliation key can therefore be forced with the _key attribute containing the list of
XPaths that make up the key (separated by commas).
It is possible to force the type of operation by populating the _operation attribute with the
following values:
insert: forces the insertion of the record (the reconciliation key is not used),
insertOrUpdate: updates or inserts the record depending on the reconciliation key (default
mode),
update: updates the record; does nothing if the data does not exist,
delete: deletes the records,
none: used only for link reconciliation, without update or insertion.
Example with the "Write" method

Updating or inserting a recipient (implicit "insertOrUpdate" operation) with e-mail address,
date of birth and town:
Deleting a recipient:
Note:
For a deletion operation, the input document must contain only the fields that make up the
reconciliation key.
Example with the "WriteCollection" method

Update or insertion for several recipients:
Note:
The name of the first <recipient-collection> element does not matter.
Example on links
Example 1
Associating the folder with a recipient based on its internal name (@name).

The "_key" and "_operation" attributes can be entered on a linked element. The behavior on this
element is the same as on the main element of the input schema.
The definition of the key of the main entity ("nms:recipient") consists of a field from a linked table
(element <folder> schema "xtk:folder") and the e-mail.
Note:
The operation "none" entered on the folder element defines a reconciliation on the folder without
update or insert.
Example 2
Updating the company (linked table in "cus:company" schema) from a recipient:
Example 3
Adding a recipient to a group with the group relation table ("nms:rcpGrpRel"):
Note:
The definition of the key is not entered in the <rcpGroup> element because an implicit key based
on the group name is defined in the "nms:group" schema.
XML collection elements

By default, all the collection elements must be populated in order to update the XML collection
elements. Data from the database will be replaced with data from the input document. If the document
contains only the elements to be updated, you must populate the "_operation" attribute on all collection
elements to be updated in order to force a merge with the XML data of the database.

Query:
118 | © Neolane 2010

Response:
Return with error:
Business oriented APIs

Business API are specific to each type of object. They have an effect on:
Deliveries, for:

Creating a delivery action, refer to SubmitDelivery (nms:delivery) [page 123],
sending a campaign (start, pause, stop, send proof),
recovering delivery logs,
Workflows:
starting a workflow,
verifying processes, etc.
Refer to Use SOAP methods in JavaScript [page 126].
Content management
Subscription management, refer to Subscribe (nms:subscription) [page 120] and Unsubscribe
(nms:subscription) [page 122].
Data processes: imports, exports.
For further information on business API, refer to the online help section JSAPI.chm.
JavaScript example of the insertion of a resource in Neolane
Subscribe (nms:subscription)
This service lets you subscribe a recipient to an information service and update the recipient profile.
The following parameters are required in order to call the service:
a session token (for authentication),
internal name of the subscription service,
an XML document containing the recipient information (from the "nms:recipient" schema),
a Boolean for recipient creation.
Description of the "subscribe" method in the "nms:subscription" schema:
The definition of the reconciliation key must be entered via the _key attribute on the <recipient>
element of the XML document. The content of this attribute is a comma-separated XPath list.
This call does not return any data, except errors.
120 | © Neolane 2010

Examples
Subscription with recipient reconciliation key on the e-mail address: the input XML document
must reference the email address and the definition of the key on this field.
Important:
In the definition of the key, the referenced XPaths do not distinguish between elements and
attributes, and the XPath of the e-mail address is therefore "email" instead of "@email".
Updating the recipient as well as the subscription.

Query:
Response:

Unsubscribe (nms:subscription)
This service lets you unsubscribe a recipient from an information service and update the recipient
profile.
Internal name of the service to unsubscribe from,
an XML document containing the recipient information (from the "nms:recipient" schema),
Description of the "Unsubscribe" method in the "nms:subscription" schema:
The definition of the reconciliation key must be entered via the _key attribute on the <recipient>
element of the XML document. The content of this attribute is a comma-separated XPath list.
If the recipient is not present in the database or is not subscribed to the concerned information
service, the service performs no action and does not generate an error.

Query:
Response:
122 | © Neolane 2010

SubmitDelivery (nms:delivery)
This service lets you create and submit a delivery action.
internal name of the delivery scenario,
an optional XML document containing additional delivery data.
Description of the method in its schema:
A delivery scenario must be created from the Neolane client console. It contains the parameters
common to all deliveries (sender address or duration of validity of the message).
The input XML document is a delivery scenario fragment that obeys the structure of the
"nms:delivery" schema. It will contain all additional data that could not be defined statically
in the scenario (e.g., list of recipients to target).
XML document example:

This example is based on a delivery scenario from an external data source (a file in this case).
The configuration is fully described in the scenario, so all that remains to be sent when the
call occurs is the content of the file from the <externalSource> element.

Query:

Response:
Implementing SOAP methods in JavaScript
Introduction
It is possible to create SOAP methods in JavaScript. This function simply enables applicative processes,
it can avoid developing JSPs and their calling in the forms.
These SOAP methods behave in the same way as those defined natively in the application. The same
attributes are supported: static, key only and const.
Definition of a method library

Creating a method library involves two stages:
The SOAP method declaration,
Definition (or implementation) in JavaScript.
124 | © Neolane 2010

Declaration
Start by declaring the methods in the schemas. Their declaration is similar to that of native
methods, except that you need to add the 'library' attribute specifying the name of the method
library where the definition is located.
This name coincides with the name (with the namespace) of the 'JavaScript Code' type entity.
Warning:
The methods implemented in JavaScript must be defined based on out-of-the-box methods.
Example:
The testLog(msg) method is declared in an nms:recipient extension
Note:
The namespace and the name used for the library are independent from the namespace and
schema name where the declaration is found.
Definition
SOAP methods are implemented in the form of JavaScript function grouped in a script
representing a library.
Note:
A method library can group functions for various schemas or vice versa, the functions of one
schema can be defined in separate libraries.
The script can contain code to be executed during initial library loading.
1. Name
The name of the function must comply with the following format:
Example:
The following JavaScript function is the implementation of the method described above. It
shall be defined in the 'JavaScript Code' type entity using the 'cus:test' name.
2. Signature

The function's signature must include an argument for each 'in' or 'inout' parameter of the declaration.
Specific cases:
non-static methods: the function must include an additional argument first, coinciding with
the XML entity passed in the form of an 'xml' (E4X) type object.
"key only" type methods: the function must include an additional argument first, coinciding
with the key passed in the form of character strings.
3. Returned values
The function must return a value for each 'out' or 'inout' type parameter. Specific case: If the method
is declared without any of the 'static', 'key only' or 'const' attributes, the first returned value must
coincide with the modified entity. It is possible to return a new object or to return the first modified
parameter.
For example:
When several values are to be returned, they must be displayed in a table.

Example:
Current limitations
These methods are not visible in WSDL.
Glossary
Method library
A set of JavaScript functions contained in a 'JavaScript Code' type entity.
Method declaration
XML entity <method> in the schema.
Method definition
Definition of the JavaScript function in the 'JavaScript Code' entity.
Signature
The list of arguments in a function and their type.
Use SOAP methods in JavaScript

This is the JavaScript executed on the Neolane server.
126 | © Neolane 2010

Static methods
Static SOAP methods are accessed by invoking a method on the object representing the schema.
Schemas are properties of 'namespace' objects. These namespaces are global variables, thus,
for example, xtk or nms variables represent the corresponding namespaces
The following example invokes the static PostEvent method of the xtk:workflow schema:
Query
Response
Non-static methods
To use non-static SOAP methods, it is necessary first to retrieve an entity using the "get" or
"create" methods on the corresponding schemas.
The following example invokes the ExecuteQuery method of the "xtk:queryDef" schema:

Examples
Query on the recipient table with a "get" operation:
Query on the recipient table with a "select" operation:
128 | © Neolane 2010

Writing data to the recipient table:
Web service calls
General information
All API methods are presented in the form of Web services. This enables you to manage all
Neolane functions via SOAP calls, which are the native entry point of the Neolane application
server. The Neolane console itself only uses SOAP calls.
Web services let you create many applications from a third-party system:
Synchronous alerts, notification, and real-time scenario execution from a back office or
transaction system,
Development of special interfaces with simplified functionality (Web interfaces, etc.),
Feeding and lookup of data in the database while observing trade rules and remaining
isolated from the underlying physical model.
Definition of Web services

The definition of the Web services implemented on the Neolane application server is available
from the data schemas.
A Web service is described in the grammar of the data schemas and is available from the
<methods> element.
Here we have an example of the definition of the method called GenerateForm.

The description of the service starts with the <method> element. The list of parameters of
the method is completed from the <parameters> element. Each parameter is specified by a
name, a type (Boolean, string, DOMElement, etc.) and a description. The "inout" attribute lets
you force the return parameter.
The presence of the "static" attribute (with the value "true") describes this method as static,
which means that all parameters of the method must be declared.

A "const" method implicitly has an XML document in the format of its associated schema as its input.
Example of the "const"-type "ExecuteQuery" method from the "xtk:queryDef" schema:
The input parameter of this method is an XML document in the format of the "xtk:queryDef" schema.
Web service description: WSDL

A WSDL (Web Service Description Library) file is available for each service. This XML file uses a
metalanguage to describe the service and to specify the available methods, parameters, and the
server to contact for executing the service.
WSDL file generation

To generate a WSDL file, you must enter the following URL from a Web browser:
http://<server>/nl/jsp/schemawsdl.jsp?schema=<schema>
With:
<server>: the Neolane application server (nlserver web)
<schema>: schema identification key
Example on the "ExecuteQuery" method of the "xtk:queryDef" schema

The WSDL file is generated from the URL:
http://localhost/nl/jsp/schemawsdl.jsp?schema=xtk:queryDef
A WSDL description starts by defining the types used to form messages, associated in "ports",
connected to a protocol by "bindings" forming Web services.
Types
Type definitions are based on XML schemas. In our example, the "ExecuteQuery" method takes an
"s:string" string and an XML document (<s:complexType>) as parameters. The return value of the
method ("ExecuteQueryResponse") is an XML document (<s:complexType>).
130 | © Neolane 2010

Messages
Describes the names and types of a set of fields to be sent. The method uses two messages
to pass as a parameter ("ExecuteQueryIn") and the return value ("ExecuteQeuryOut").
PortType
Associates the messages on the "ExecuteQuery" operation triggered by the query ("input")
generating a response ("output").
Binding
Specifies the SOAP communication protocol (<soap:binding>), data transport in HTTP (value
of the "transport" attribute) and the data format for the "ExecuteQuery" operation. The body
of the SOAP envelope contains the message segments directly without transformation.

Service
Describes the "XtkQueryDef" service with its URI on the URL of the Neolane application server.
Connectivity
When you use external SOAP APIs, you need to use a session token that conveys the login used and
ensures authentication.
There are two possible authentication modes:
via a logon: login + Neolane password which creates a session token. The session token expires
automatically after a certain amount of time,
or
via the login + password stored in the application: this operating mode requires an https connection
to secure exchanges.
It is also possible to use an authentication via the IP address (trust), which enables you to sidestep
the password.
For more on this, refer to Safety: authentication mechanism [page 132]
Safety: authentication mechanism

SOAP calls incorporate an authentication mechanism based on a login and application password.
These are sent to the SOAP envelope from a string with the "login/password" format or from a session
token.
A session token is an encrypted string representing the login and application password. The advantage
of the session token is that it avoids the need to send an unencrypted login and password.
The following example represents two authentication strings based on the same login:
login/password:
session token:
Tip:
To retrieve a session token associated with a login, you must connect to the client console using the
desired login and retrieve the session token value ("__sessiontoken") from the page properties of
the home page.
132 | © Neolane 2010

Important:
The application login used for authentication must be configured in the Neolane client console
with the rights and restrictions on the database data.
When the authentication string is not completed in the SOAP call, an intermediate page is
automatically displayed. This enables you to enter a login and password to return a valid session
token.
Note:
You can use the "HTTPS" protocol to secure exchanges so that unencrypted data is not sent
through the network. You must then configure the Web server that hosts the Neolane Web
services.
The validity period of the session token is defined via the

shared/authentication/@sessionTimeOutSec parameter of the file.
The default value is 86400, i.e. 1 day.
For the netreport application, the encrypted session token with an expiry deadline cannot be
used. We recommend using the monitoring login and authenticating it for the IP addresses of
the machines to be monitored. This will enable you to log on without a password. For more
on this, refer to the Production guide, "Automatic surveillance via Neolane scripts".

Examples of programs in various languages
We will use the "ExecuteQuery" method of the "xtk:queryDef" schema presented in the previous
sections. This method takes an authentication string and an XML document describing the query to
be sent as parameters. The return parameter is an XML document (compliant with the schema of
the table to which the query refers) containing the result of the query.
Java
134 | © Neolane 2010

PHP
The following example uses the PEAR SOAP library.

C#
To use the SOAP service, you must generate dedicated classes (wrapper) from the WSDL file. The
steps to apply are as follows:
1 Generate the WSDL file ("queryDef.wsdl") of the "xtk:queryDef" schema:
http://.../nl/jsp/schemawsdl.jsp?schema=xtk:queryDef
2 Launch the command (from Visual Studio .NET):
3 Include the "queryDef.cs" file generated in the project.
The application source code:
136 | © Neolane 2010

Visual Basic

Appendix 1 - Examples
PHP examples
Writing to the database
Writing to the database with the "Write" method from an input form:
138 | © Neolane 2010

The SOAP response is displayed when the form is validated:
HTML page of the input form:
Source code:

Subscription to a service
Subscription to a service with the "Subscribe" method and updating of certain profile fields.
Note:
A drop-down list displays the services that are active in the database.
HTML page of the input form:
140 | © Neolane 2010

Source code:

C# example
Example of writing data to the recipient table with retrieval of a valid identifier.
142 | © Neolane 2010

JSP example
Reads from and writes to the database using the "ExecuteQuery" and "Write" methods from
an input form.

This example uses the classes developed by Neolane in order to simplify SOAP method calls.
Source code:
144 | © Neolane 2010

146 | © Neolane 2010
Appendix 2 - Using SOAP to collect data from a profile
Queries
The first step consists in collecting the data from the profile. To achieve this, you must use
the ExecuteQuery method of :
This method involves two parameters:
sessiontoken: identifier/password
document: XML document defining the query
The following is an example of an XML document defining the query:

The following is a full example of a SOAP query. Note that the identifier used is internal, temporarily
without a password.
This query must be made using the /nl/jsp/soaprouter.jsp URL of your Neolane application server:
http://myserver.neolane.net/nl/jsp/soaprouter.jsp
Restricting the number of records to be recovered

To restrict the number of records to be recovered in your response, add the firstRows and lineCount
attributes to the queryDef element.
Example:
To recover the next 100 records, use the same query again and add the attribute.
Example:
148 | © Neolane 2010

Tip:
The index of the first line is set to zero, therefore enables you to go to the
start of the list.
Tip for designing queries

To help you find the exact syntax for your query, you can design it using the generic query
editor, using the Tools > Generic query editor menu.
For further information, refer to Query-building tip: [page 112]
Using data from the profile

The SOAP call response is an XML document with the following form:
In our example, we find the requested data from the profile (account, email, format and
mobilePhone) and the list of active subscriptions.
Submitting modifications
To submit the modifications made to the profile, you must create a Web form, then call the
ValidateForm method of the nms:webForm schema on this form.
This method involves three parameters:
sessiontoken: identifier/password,
formName: name of the form,
recipients: modified data of the profile.
Example of a SOAP call for modifying a profile:

150 | © Neolane 2010
CHAPTER 5
Using an existing recipient
table
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
View attribute . . . . . . . . . . . . . . . . . . . . . . . . 152
Names of tables and columns . . . . . . . . . . . . . . . . . . . 152
Indexed fields . . . . . . . . . . . . . . . . . . . . . . . . 153
Calculated fields . . . . . . . . . . . . . . . . . . . . . . . 153
Automated schema generation . . . . . . . . . . . . . . . . . . 154
Setting up a delivery mapping . . . . . . . . . . . . . . . . . . . . 155
Configuring the schemas linked to the recipient table . . . . . . . . . . . 155
Creating a delivery mapping . . . . . . . . . . . . . . . . . . . 162
Using delivery mapping . . . . . . . . . . . . . . . . . . . . . 163
Group-type list and filter configuration . . . . . . . . . . . . . . . . . 163
Group-type lists . . . . . . . . . . . . . . . . . . . . . . . . 163
Application filters . . . . . . . . . . . . . . . . . . . . . . . 165
Introduction
This section describes how Neolane exploits data stored in an existing database, separate from
the application database, without duplication of data; and how it uses this data as the basis
for profiles for deliveries. This functionality provides several advantages:
No update stream to and from the Neolane database,
No changes in the processes operating on the existing database,
Neolane v5.1 - Configuration Guide - Using an existing recipient table | 151

Use of a database of profiles with a structure other than the standard one,
Possibility of broadcasting with one instance to profiles saved in different tables, with different
structures.
This section describes the key points that let you map existing tables in Neolane and the configuration
to apply to execute deliveries based on any table. Finally, it describes how to provide users with
query interfaces as practical as those available with the standard recipient table. To understand the
material presented in this section, familiarity with the principles of screen and schema design is
required.
Overview
The characteristics of a schema that references an existing table are as follows:
Neolane must not modify SQL objects relative to existing tables,
The names of tables and columns must be specified explicitly,
Indexes must be handled in a particular way.
View attribute
Source schemas accept the view attribute for the srcSchema root element. The view="true"
attribute tells the database structure update wizard to ignore this schema. The application is therefore
prohibited from synchronizing the table, its columns and its indexes with the corresponding schema.
When this attribute is set to true, the schema is used only to generate SQL queries to access the
data of this table.
Names of tables and columns

When tables are created by the table update wizard, the names of tables and columns are generated
automatically based on the names of the respective schemas and attributes. It is however possible
to force the SQL names to be used by entering the following attributes:
sqltable in the main element of the schema, to specify the table,
sqlname in each attribute, to specify the columns.
Example:
In Neolane, to use the existing PARAM_DATE table of the fid database, which contains the Time_ID
(integer) and FullDate (varchar) columns, the schema is as follows:
152 | © Neolane 2010

In this example, if the names of the tables and columns had not been explicitly specified, the
application would have used CusDate for the table, iTimeId and sFulldate for the columns.
In a schema, it is possible to populate only part of the columns of an existing table; the
unpopulated columns will not be user-accessible.
Indexed fields
When sorting the records of a list from the client console, better performance is obtained by
sorting on indexed fields. Declaring an index in a schema makes the console display the indexed
fields with a red line under the sort-order arrow to the left of the column label, as in the screen
below:
In a schema, an index is defined as follows:
An index is implicitly declared for each key and link declaration of the source schema. Declaration
of the index can be prevented by specifying the attribute noDbIndex="true":
Example:
Calculated fields
It is still possible to define calculated fields in the context of a mapping. You can use the
predefined expressions and functions of Neolane by referencing other fields with XPath
expressions. You can also use SQL expressions directly using the [SQLDATA[expression_sql]]
escape sequence.
Example:
Using Neolane expressions with XPath expressions:
Using SQL expressions:

Using Neolane functions and SQL data:
Automated schema generation

When a large number of tables and columns need to be mapped in Neolane, it is preferable to
automate some of the schema writing work. Here we provide a guide to schema mass-production,
bearing in mind that every case has its own specific features.
The SQL module of the Neolane server lets you export the description of all the tables in a database
to an XML file:
If the database to be explored does not host a Neolane instance, a new instance should be declared
in the command line.
Instance creation:
Declaration of the database connection:
These commands do not trigger the creation of SQL objects specific to the Neolane application; they
only define a way of connecting to the database.
The XML file produced will look like this:
154 | © Neolane 2010

Based on this data, an XSL stylesheet can be used to generate the corresponding source
schema, for example.
Setting up a delivery mapping

Creating delivery mapping is necessary in two cases:
if you use a recipient table other than the one provided by Neolane,
if you configure a filtering dimension which is different from the targeting dimension on
the delivery mapping screen.
If one of these situations applies to you, please follow the steps detailed in the following
sections.
Configuring the schemas linked to the recipient table

Before you create a delivery mapping, you must perform a number of settings in order for
Neolane to operate with a new recipient data schema.
In order to do this, comply with the following steps:
1 Create a new, relatively simple, data schema from which to perform delivery.
Note:
For further information, refer to the data schema documentation.
In our example, we will create a customer schema, which will be a very simple table
containing the following fields: registration number, first name, last name, e-mail address,
mobile phone number. The target is to be able to send e-mail or SMS alerts to the persons
stored in this table.
Example schema (cus:customer)

2 Declare your schema as an external view using the ="true" attribute. Refer to View attribute
[page 152].
3 If you need to add a postal address, please use the following type of structure:
4 Change the content of the home page so that it points towards the new recipient schema.
For further information, refer to Home page [page 177].
5 Create a new schema for the tables of the delivery logs, exclusion logs and tracking logs based
on the out-of-the-box nms:broadLog schema.
Example schema for customer delivery logs:
156 | © Neolane 2010

Example schema for customer exclusion logs:
Note:
Creating schemas for exclusion logs isn't mandatory. However, it is recommended in the
case of large delivery volumes.
Example schema for customer tracking logs:
6 Create a xtk:navtree XML document to declare your new recipient schema.

7 Change the nms:delivery delivery schema to specify the new delivery, exclusion and tracking
logs of the deliveries.
8 Next, launch the database structure update wizard to create the table. Also insert a few records
for test purposes.
Seed address configuration

If you want to use seed addresses during your deliveries, you need to change the nms:seedMember
schema in order to reference the new recipient table.
For further information, refer to Seed list management [page 80].
158 | © Neolane 2010

Offer configuration
If you are using the Offer management module, you must change the nms:proposition
schema in order to specify the new delivery log schema.
For further information, refer to Offer management with a recipient table outside of Neolane
[page 236].
Hypothesis configuration
If you are using the Response management module, you must extend the nms:remaMatch
schema in order to create a link towards the new delivery log schema.
For further information, refer to Response management with a recipient table outside of Neolane
[page 231].
Coupon configuration
In order to use the coupon management module on a schema other than nms:recipient, you
need to create an extension schema of nms:couponvalue.
There are two possibilities:
1 If you only need one targeting dimension, simply change the target in the link. For example,
to add a link related to a customer, add the following code:
The overall schema must be shown as follows:
2 However, to define two links, simply make the same change and add the following lines
of code:
The overall schema must be shown as follows:

Survey configuration
If you use surveys, implement this procedure:
1 Create a new schema for recipient survey response tables on the out-of-the-box nms:webAppLog
schema to reference the recipient table outside of Neolane.
Example schema (cus:customer):
2 Change the nms:webApp form to specify the recipient table outside of Neolane and disable the
zoom.
Example schema for form modification:
In the response list, webAppLogRcp occurences are replaced with webAppLogClt and
recipient occurrences are replaced with customer to specify the new recipient table.
The zoom attribute is added and its value set to false to disable zooming in surveys.
160 | © Neolane 2010

3 In the Neolane console, create a survey template whose schemas reference the external recipient
table and the new response form created during stage 2.
Creating a delivery mapping

To allow users to select the "customer" table in a delivery scenario, you must create a delivery
mapping to indicate where to find the information required for a delivery (e-mail address, etc.). To
do this:
1 Open the Campaign execution>Administration>Delivery mapping node. This folder
contains the native mappings of the application (Recipients, Subscriptions, etc.). They are shown
in bold to distinguish them from user-defined mappings.
Two targeting dimensions are available on recipients, operators or subscriptions. The targeting
and filtering dimensions are the same, except in the case of subscription mapping, where recipients
are targeted based on their subscription to a service.
2 Create a new mapping and name it "Customers".
Indicate the schema concerned (cus:customer).
3 Enter the information for this mapping.
The Mapping lists the fields that can be used by the delivery.
For each of these fields, you can enter an expression to calculate its value. In general, this will
simply be a field of the mapping schema, but you can also use a constant or a more complicated
formula.
162 | © Neolane 2010

The "Delivery address" section indicates the location of the recipient address for each
delivery channel. If one of these parameters is not populated, this mapping cannot be
used on the channel concerned.
For the postal address, the parameter to be populated must be an element defined
according to the "postalAddress" template of the "nms:common" schema. This element
includes various address lines and information on the quality of the postal address.
All the other fields are optional. The blacklist indicators are Boolean values to indicate
if the recipient no longer wishes to be contacted. The same field can be used for all
channels. The format concerns the e-mail reception format (0 unknown, 1 text, 2
HTML). The external identifier is a free text field propagated on the delivery logs.
In our example, we are managing two channels (e-mail: "@email", SMS: "@mobile")
and there is no blacklist indicator.
You can add additional information collected during targeting. To do this, add the
attribute(s) in the new delivery log schema (refer to Setting up a delivery mapping
[page 155]). In the Storage subtab, create as many [targetData/@xxx] expressions
as necessary for these additional fields.
As soon as the expression is defined in upstream targeting, it becomes valid and will
be stored in Neolane.
One destination field can be used several times in the list with different expressions.
Neolane will use the first valid expression in the list.
Using delivery mapping

To use the new schema as the target of a delivery, simply select the mapping created at the
top of the recipient selection page in the delivery wizard.
Group-type list and filter configuration

To offer the user an environment similar to the one that exists with the recipient table,
particularly advanced targeting, the following aspects must be managed:
Group-type lists,
Application filters ("segments" in the case of recipients).
Group-type lists
Presentation
A group-type list is a fixed selection of existing unique recipients (unique primary key). A
group-type list is normally used to record the result of a targeting, in which case the list is a
snapshot of the result of a query or an advanced segmentation. It is not updated when the
database evolves. The user can manually add or remove certain profiles from the list: this type
of operation does not create new profiles or delete existing profiles.

Warning:
List management no longer requires the use of a relationship table. You can always base yourself on
a profile/list relationship schema if necessary, however this will impact Neolane's performance.
Creating a profile-list relationship schema

The NmsGroup table provides the lists, and the NmsRcpGrpRel table records the belonging of
recipients to lists.
To give users the same list operation with a different NmsRecipient table, it is necessary to:
create a new relationships table with similar links,
adapt the list screen.
If we wish to give the functionality of the lists to the customer table, the proposed schema, which is
very close to the "nms:rcpGrpRel" schema, is as follows:
Note in particular the definitions of integrity on the links (integrity and revIntegrity properties): the
deletion of a customer-list relationship must not lead to the deletion of a list or a customer. On the
other hand, the deletion of a customer or list must lead to the deletion of the relationship.
One final detail is, however, missing from this adjustment: as soon as it is possible to have lists of
recipients or customers, it becomes necessary to specify which of these two tables a list refers to.
We will therefore extend the nms:group schema to add an indicator of the table used. To do this,
we use the targetSchema enumeration of nms:broadLog (see above: Extension of the delivery log
schema "nms:broadLog"):
164 | © Neolane 2010

The default value entered indicates that when the user creates a list it will be a list of customers
by default.
Adaptation of the list screen

The list screen must be duplicated (or modified, but in this case it must be readapted each
time its standard version is updated) in order to display the list of customers in addition to the
list of recipients. The right list must therefore be displayed based on the value of
@targetSchema. To do this, we use visibleGroup container controls:
Application filters
Once the schema corresponding to the table of profiles to be used has been created, application
filters can be created, as for any schema, making sure the Nms_defaultRcpSchema option
is modified to declare the new profile table. These filters will be available in the target selection
screen in the same way and with the same functionality as the segments for the recipients
(possibility of using parameter input forms, hierarchical folder organization, etc.).
It is recommended that you re-create the main existing recipient filters for specific schemas
(subject to the filters being applicable to these schemas), in particular:
Recipients of a delivery action,
Recipients of a campaign,

A recipient,
A group of recipients: recreate this filter with the following condition:
To give it priority in the filter selectors, select the "Main filter" option in the advanced filter parameters.
166 | © Neolane 2010

CHAPTER 6
Neolane Graphical interface
Table of Contents
Navigation hierarchy . . . . . . . . . . . . . . . . . . . . . . . 168
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 170
Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Home page . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 181
Rendering of the Neolane console . . . . . . . . . . . . . . . . . . 182
Home page . . . . . . . . . . . . . . . . . . . . . . . . . 183
Email notifications . . . . . . . . . . . . . . . . . . . . . . . 184
Dashboards and schedules . . . . . . . . . . . . . . . . . . . . 186
Web applications . . . . . . . . . . . . . . . . . . . . . . . 187
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Creating a Web application . . . . . . . . . . . . . . . . . . . . 188
Creating a filter on a folder . . . . . . . . . . . . . . . . . . . . 191
Creating a button to configure a new Web application . . . . . . . . . . 193
Adding a detail . . . . . . . . . . . . . . . . . . . . . . . . 193
Filtering and updating the list . . . . . . . . . . . . . . . . . . . 195
Integrating a Web application on the home page . . . . . . . . . . . . 200
Neolane v5.1 - Configuration Guide - Neolane Graphical interface | 167

Navigation hierarchy
Overview
The navigation hierarchy works like a file browser (e.g. Windows Explorer). Folders may contain
sub-folders. Selecting a node displays the view corresponding to the node.
168 | © Neolane 2010

The view displayed is a list associated with a schema and an input form to edit the selected
line.
Figure 6.1. Neolane Browser
To add a new folder to the tree, right-click the folder in the branch where you wish to insert
a folder, and select Add new folder. In the shortcut menu, select the type of file to be created.

Configuration
The types of folders used by the navigation list are described in an XML document that obeys the
grammar of the xtk:navtree schema.
The XML document is structured as follows:
The XML document contains the <navtree> root element with the name and namespace attributes
to specify the document name and namespace. The name and namespace make up the document
identification key.
The global commands of the application are declared in the document from the <commands>
element.
The declaration of file types is structured in the document with the following elements: <model>
and <nodeModel>.
Global commands
A global command lets you launch an action. This action can be an input form or a SOAP call.
Global commands are accessible from the main Tools menu.
170 | © Neolane 2010

The command configuration structure is as follows:
The description of a global command is entered in the <command> element with the following
properties:
name: internal name of the command: the name must be entered and unique
label: label of the command.
desc: description visible from the status bar of the main screen.
form: form to be launched: the value to be entered is the identification key of the input
form (e.g. "cus:recipient")
rights: list of named rights (separated by a comma) allowing access to this command.
The list of available rights is accessible from the Administration/Access
management/Named rights folder.
promptLabel: displays a confirmation box before execution of the command
A <command> element can contain <command> sub-elements. In this case, the parent
element lets you display a sub-menu made up of these child elements.
The commands are displayed in the same order as they are declared in the XML document.
A command separator lets you display a separation bar between commands. It is identified by
the '-' value contained in the command label.
The optional presence of the <soapCall> tag with its input parameters defines the call of a
SOAP method to be executed. For further information on the SOAP API, refer to the jsapi.chm
online help section.
The form context can be updated on initialization from the <enter> tag. For further information
on this tag, refer to the documentation on input forms.
Example:
Declaration of a global command to launch the "xtk:import" form:

A keyboard shortcut is declared on the 'I' character by the presence of & in the command
label.
Example of a sub-menu with a separator:
Execution of a SOAP method:
Folder type
A folder type lets you give access to the data of a schema. The view associated with the folder consists
of a list and an input form.
The folder type configuration structure is as follows:
The folder type declaration must be entered under a <model> element. This element lets you define
a hierarchical organization visible from the Add new folder menu. A <model> element must
contain <nodeModel> elements and other <model> elements.
The name and label attributes populate the internal name of the element and the label displayed
in the Add new folder menu.
172 | © Neolane 2010

The <nodeModel> element contains the description of the folder type with the following
properties:
name: internal name
label: label used in the Add new folder menu and as a default label when inserting a
folder.
img: default image on folder insertion.
hiddenCommands: list of commands (separated by a comma) to be masked. Possible
values: "insert", "delete", "update" and "duplicate".
newFolderShortCuts: list of shortcuts on models (<nodeModel> separated by a comma)
in folder creation.
insertRight, editRight, deleteRight: rights for inserting, editing and deleting folders.
The <view> element under the <nodeModel> element contains the configuration of the
list associated with the view. The schema of the list is entered in the schema attribute of the
<view> element.
To edit the records of the list, the input form with the same name as the list schema is implicitly
used. The type attribute on the <view> element affects the display of the form. Possible
values are:
listdet: displays the form at the bottom of the list.
list: displays the list alone. The form is launched by double-clicking or via the "Open" in
the menu on selecting the list.
form: displays a read-only form.
editForm: displays a form in edit mode.
Note:
The name of the input form can be overloaded by entering the form attribute in the <view>
element.
The default configuration of the list columns is entered via the <columns> element. A column
is declared on a <node> element containing the xpath attribute with the field to be referenced
in its schema as its value.
Example: declaration of a folder type on the "nms:recipient" schema.

The corresponding folder insertion menu:
A filter and sort can be applied when loading the list:
Shortcut commands
A shortcut command lets you launch an action on selecting the list. The action can be an input form
or a SOAP call.
Commands are accessible from the Action menu of the list or the associated menu button.
The command configuration structure is as follows:
The description of a command is entered on the <command> element with the following properties:
name: internal name of the command: the name must be entered and unique.
label: label of the command.
desc: description visible from the status bar of the main screen.
form: form to be launched: the value to be entered is the identification key of the input form
(e.g. "cus:recipient").
rights: list of named rights (separated by a comma) allowing access to this command. The list
of available rights is accessible from the Administration/Access management/Named rights
folder.
promptLabel: displays a confirmation box before execution of the command.
174 | © Neolane 2010

monoSelection: forces mono-selection (multiple selection by default).
refreshView: forces reloading of the list after execution of the command.
enabledIf: activates the command depending on the expression entered.
img: enters an image allowing access to the command from the list toolbar.
A <command> element can contain <command> sub-elements. In this case, the parent
element lets you display a sub-menu made up of these child elements.
The display of commands observes the order of their declaration in the XML document.
A command separator lets you display a separation bar between commands. It is identified by
the '-' value contained in the command label.
The optional presence of the <soapCall> tag with its input parameters defines the call of a
SOAP method to be executed. For further information about SOAP APIs, refer to the jsapi.chm
online help section.
The form context can be updated on initialization via the <enter> tag. For further information
about this tag, refer to the input form documentation.
Example:
Linked folder
There are two types of folder management operations:
1 The folder is a view: the list displays all records associated with the schema, with the
possibility of system filtering entered in the folder properties.
2 The folder is linked: the records in the list are implicitly filtered on the folder link.
For a linked folder, the folderLink attribute on the <nodeModel> element must be populated.
This attribute contains the name of the link on the folder configured in the data schema.
Example of declaration of a linked folder in the data schema:
The configuration of the <nodeModel> on the link of the folder named "folder" is as follows:

Editing
The screen for creating and configuring the navigation hierarchy configuration documents is accessible
via the Administration/Configuration/Navigation hierarchies node:
The navigation hierarchy configuration is divided over several XML documents. It operates on a similar
principle to schema extension: all documents are merged to generate a single document containing
the whole configuration. This document cannot be edited, and is displayed via the "Preview" tab.
The edit field provides the content of the XML document:
176 | © Neolane 2010

Note:
The "Name" edit control lets you enter the document key consisting of the name and
namespace. The "name" and "namespace" attributes of the <navtree> element are
automatically updated in the XML edit field of the schema.
The preview automatically generates the merged document containing the complete
configuration:
Home page
During connection to the client interface, the Neolane home page is displayed by default. It
enables the user to access the various Neolane modules available in the application. This home
page may however be customized to change its content and aspect. The following section
describes how to configure the Neolane home page based on your needs, including for displaying
applications other than those provided by Neolane.
Structure
The home page is made up of several sections that coincide with the various Neolane modules
or with each user application installed on your workstation.

In the following example, the Delivery and Platform modules have been installed and are therefore
accessible via the home page.
The content of the home page is configured in XML documents available via
Administration/Configuration/Navigation hierarchies.
For each out-of-the-box module or installed application, there is a document that obeys the grammar
of the xtk:navtree schema.
For example, the out-of-the-box file coincides with the Delivery module, the
file coincides with the Campaign module, and the file with the MRM module, etc.
For more information on the xtk:navtree schema, refer to Navigation hierarchy [page 168].
The following document coincides with the following home page:
178 | © Neolane 2010

Elements and attributes
Here are the main elements to be used for configuring the home page:
<application> provides the application to be displayed in the home page thanks to the
following attributes:
name: lets you identify the module or the application.
ownLabel: represents the first part of the application name (blue on the Neolane page).
label: represents the second part of the application name (orange on the Neolane page).
order: defines the order of appearance of the application on the page. The highest number
places the application last.
Example of an MRM application declaration:
<summary> : text presenting the application on the page.

Example of a description of the Campaign application:

<view>: matches a link in an application and lets you open a screen. It is identified by its name
(name) and behaves differently depending on its type: sub-view (<view>), Web application
(webApp), URL or jssp (url).
Each view has a label (label), an internal name (name), a folder type (folderModel), an icon
(img), a display order on the page (order) and a display condition (applicableIf=).
<view> coincides with a sub-menu.
Example of sub-menu declaration for the Profiles and targets view.
webApp matches a Neolane Web application. Refer to the Advanced user guide for further
information.
Example of a view pointing towards the Web application for recipient overview:
url refers to the object to be edited and lets you display a jssp, form or page.
Example of a URL that lets you open the package import form:
180 | © Neolane 2010

Example of a URL that lets you open the report jssp page:
Example of a URL that lets you open the plan schedule page:
Configuration
You can tailor the existing home page, change it altogether or create an additional page.
Warning:
Remember that you must not modify the out-of-the-box files. The Neolane console will not let
you do so since the files are in read-only format. However, if the files were modified, the
console could no longer be updated automatically.
Personalizing page content

To modify the content of the existing home page, create a new xtk:navtree document
via Administration/Configuration/Navigation hierarchies.
Integrate the <application> and <view> elements to point towards the installed
application(s) and create or modify views.
You can declare several applications in the same file if necessary; simply repeat the
<application> element for each one.
It is also possible to extend the parameters already in your xtk:navtree file to include
out-of-the-box Neolane modules or to add a view.
For example, to mask stocks, insert the following syntax in your XML document:
Replacing the existing home page

You can create a new page to be displayed when Neolane is connected.
Create a type file.

You can base yourself on the default home page file, , available here:
.
More specifically, the xtk.session.GetActiveApplicationMenus() tag lets you recover the list
of available applications for the current login and browse its content.
Create a xtk:navtree type document if you haven't created on already.

Make it point towards the file created previously using the <windows> and </windows>
elements as shown below:
The <windows> element lets you create a tab container, the <window> element lets you
create a tab and the url attribute lets you reference the jssp document of the home page.
You may then insert <application> and <view> elements to reference your applications and
your views.
If you wish to replace the default Neolane home page, create a new file with your own content.
Create a xtk:navtree document and point it towards the new file.
Rendering of the Neolane console

You can modify all the images and logos displayed in Neolane. This concerns the home page,
notifications, dashboards, overview or report-type Web applications.
182 | © Neolane 2010

Home page
To change the presentation of the home page, you need to create a new style sheet,
extend the parameters of your xtk:navtree type document in order to reference the new
style sheet and make any required changes to the images in the Neolane installation folder.
Here is an example of a modification made to the home page:
To obtain the home page shown above, apply the following steps:
1 Create a style sheet ( in our example) and overload the styles of the HTML
rendering.

2 Reference the style sheet in the xtk:navtree document.
The title of the page is contained in the title attribute and that of the footer in the footer element.
3 Modify the header image here: .
Email notifications
Here is an example of a rendered email notification.
Notifications are mainly made up of the following elements:
184 | © Neolane 2010

an HTML header
three images available in the Neolane installation folder: .
To customize a notification, you can replace the images provided by default and modify the
header to match.

Dashboards and schedules
Campaign dashboards and schedules (delivery calendar, marketing plan, program and campaign
schedules, etc.) use a logo available in the Neolane installation folder:
.
Simply modify this image to customize your dashboards with your own company logo for example.
186 | © Neolane 2010

Web applications
Overview type Web applications use a logo contained in the Neolane installation folder:
.
Simply modify this image to customize your overviews with your own company logo for example.
Overview
In the following example, we will create an overview-type Web application to display all the
Web applications in your database. Configure the following elements:
a filter on the folder (refer to Creating a filter on a folder [page 191]),
a button for creating a new Web application (refer to Creating a button to configure a new
Web application [page 193]),
detail display for each entry in the list (refer to Adding a detail [page 193]),
one filter per link editing tool (refer to Creating a filter using a link editor [page 196]),

a refresh link (refer to Creating a refresh link [page 198]).
For further information on web applications, refer to Web applications [page 201].
Creating a Web application

1 Create a single Page Web application and disable outbound transitions and transitions to the
next page.
2 Changing the page title.

This title will appear in the overview header and in the web application overview.
188 | © Neolane 2010

3 In the web application properties, modify the rendering of your application by selecting
the Single-page Web application template.
4 Open the Page activity of your web application and open a list (Static element>List).
5 In the Data tab of your list, select the type of Web applications document and the
Label, Created on and Type output columns.

6 In the Filter sub-tab, create the following filter as shown below in order to display web applications
only and exclude templates from your view.
7 Close the configuration window of your page and click Preview.
190 | © Neolane 2010

The list of Web applications available in your database is displayed.
Creating a filter on a folder

In an overview, you can choose to access data depending on its location in the Neolane tree.
This is a filter on a folder. Apply the following process to add it to your overview.
1 Place your cursor on the Page node of your web application and add a Select folder
element (Input zones>Select folder)
2 Modify its label.
3 In the General tab, select Use a local variable.
4 In the Storage tab, click the Edit variables link and create the xml type variable.
Note:
The name of your variable must match the name of the element linked to the folder (defined
in the schema), i.e. in this case. You must re-use this name when you reference
the table.

5 Select the Refresh page interaction.
6 Place your cursor on your list, and in the Advanced tab, reference the variable previously created
in the XPath folder filter tab of the list. You must use the name of the element concerned by
the folder link, i.e. .
Note:
At this stage, the Web application is not within its application context, the filter can therefore not
be tested on the folder.
192 | © Neolane 2010

Creating a button to configure a new Web application
1 Place your cursor on the Page element and add a link (Input zones>Select folder).
2 Modify the link label since it will appear on the button in the overview.
3 Insert the following URL in the URL field:
xtk://open/?schema=nms:webApp&form=nms:newWebApp and choose to display the URL
in the same window.
nms:wepApp coincides with the Web application schema.
nms:newWebApp coincides with the new Web application creation wizard.
4 Add the web application icon in the image field: .
This icon will appear on the New button.
5 Enter in the Style field.
This style is referred to in the Single-page Web application template selected previously.
Adding a detail
When you configure a list in your overview, you can choose to display additional details for
each entry on your list.
1 Place your cursor on the previously created list element.

2 In the General tab, select the Columns and additional detail display mode in the drop-down
list.
3 In the Data tab, add the Primary key, Internal name and Description column and select
the Hidden field option for each one.
This way, this information will only be visible in the detail of each entry.
194 | © Neolane 2010

4 In the Additional detail tab, add the following code:
For more information on adding details to the overview, refer to Adding details [page 214].
Filtering and updating the list

In this section, you will create a filter for displaying the overview of Web applications created
by a specific operator. this filter is created with a link editor. Once you have selected an
operator, refresh the list to apply your filter; this requires creating a refresh link.
These two elements will be grouped in the same container in order to be graphically grouped
in the overview.
1 Place your cursor on the Page element and select Container>Standard.

2 Set the number of columns to 2, so that the link editor and the link are next to each other.
For information on element layout, refer to "Web applications and online surveys" in the Advanced
user guide.
3 Apply dottedFilter.
This style is referred to in the Single-page Web application template selected previously.
Creating a filter using a link editor

1 Place your cursor on the container created during the previous stage and insert a link editor via
the Input zone menu.
2 Modify the label.
It will appear next to the Filter field in the overview.
196 | © Neolane 2010

3 Select Use a local variable and choose the Operator table as an application schema.
4 In the Storage tab, click the Edit variables link and create an XML variable for filtering
data.
5 Place your cursor on the list element and create a filter via the Data>Filter tab.

Value Operator Value Taken into ac-
count if
Foreign key of the equals $(var2/@id) '$(var2/@id)'!=''
'Created by' link
Warning:
To access the informaiton, the operator of the Web application must be identified in Neolane. This
type of configuration will not work in case of anynomous Web applications.
Creating a refresh link

1 Place the cursor on the container and insert a link via the Static element menu.
2 Modify the label.
3 Select Refresh data in a list.
198 | © Neolane 2010

4 Add the previously created list.
5 Add the refresh icon on the Image field: .

6 Using the sort-order arrows, reorganize the various elements of your web application as
shown below.

The Web application is now configured. You can click the Preview tab to preview it.
For comprehensive information on Web applications, refer to the Advanced user guide.
Integrating a Web application on the home page

To display your Web application on the home page of the Neolane console, you need to extend the
xtk:navtree document and insert the following line:
The APPxx attribute must coincide with the internal name of your Web application.
For further information on how to configure the home page, refer to Home page [page 177]
200 | © Neolane 2010

CHAPTER 7
Web applications
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . 201
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 202
Web applications . . . . . . . . . . . . . . . . . . . . . . . . 203
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . 203
Implementation . . . . . . . . . . . . . . . . . . . . . . . 203
Examples of overview configuration . . . . . . . . . . . . . . . . . 207
Example of an editing form configuration . . . . . . . . . . . . . . . 224
Introduction
Presentation
Neolane incorporates a graphical module for defining and publishing web applications. This is
used to create pages, such as an editing form on an extranet, or notification forms including
data from the database with tables, charts, input forms, etc. This functionality lets you design
and post web pages where users can look up or enter information.
This chapter presents Web application management.
Main functionality
The web applications in Neolane give access to the following functionality:
Neolane v5.1 - Configuration Guide - Web applications | 201

Creating multiple-page forms,
Managing multilingual surveys with an integrated translation tool,
Graphical page management interface, multiple-column page layout,
Personalizing field rendering and position,
Conditional display of survey fields depending on answers,
Random display of questions,
Conditional page display,
Information check before validation depending on the expected data type (number, e-mail address,
date, etc.) and the mandatory fields,
E-mail invitations or notification,
Personalization of error and end messages,
Adding of images, videos, hypertext links, captcha, etc.
Monitoring of responses in real time.
The (Survey) optional creation module offers the following additional functionality:
Dynamic extension of the database: creation of responses not included in the initial data template,
Generating dedicated reports.
Compared to web applications, surveys have a simplified graphical interface with a reduced number
of edit controls.
Note:
Surveys and Web forms in Neolane are presented in the Advanced user guide.
Implementation steps
To create and post a web application, you must:
1 Create the content (fields, lists, tables, graphs, etc.).
You can also view the section presenting the available fields for surveys: all these fields are also
available for Web applications. this information is available in the Advanced user guide.
2 As required, you can add preloading, test, and saving steps, and configure the access control
system (mainly within the framework of an extranet publication).
3 Publishing the web application to make it available on an extranet or in Neolane.
Configuration
Web applications are stored in the Campaign execution>Resources>Web forms node of the
Neolane tree. The configurations are divided over the following folders:
Administration>Configuration>Form renderings: contains the rendering templates for the
web form presentation (applications and surveys). The template enables you to generate the
form. It also uses a CSS stylesheet. This stylesheet can be overloaded at the template level. For
more on this, refer to the Advanced user guide.
Campaign execution>Resources>Web forms>Web application templates: contains
form templates. To create a form, you must start with a template.
202 | © Neolane 2010

Note:
Two templates are provided with Neolane: a template to create your first web
application, and another to create your first survey.
You can convert an existing Web application into a template. To do this, select the
form and right-click. Select Actions>Save as template....
Web applications
Presentation
Neolane lets you create dynamic and interactive web applications with data from the database
and with content adapted to the rights of the connected user.
There are two types of web applications:
1 Overviews
Web applications are used in Neolane v5 to display information in the form of dashboards,
e.g. the list of recipients, status of deliveries, list of campaigns, stock management window,
etc. They then mainly allow data to be viewed and added. You can add data via the Neolane
interface, but this requires integration and appropriate expertise.
2 Extranet-type editing forms
Neolane lets you create web applications intended to be displayed on a web platform or
in an extranet context, for example. They then let you edit the data and save it in Neolane.
In this case, you can restrict access to authenticated users (via access control) and set up
data preloading based on several criteria.
Implementation
Warning:
It is highly recommended that the configurations applied be continually checked in order to
detect any errors early in the web application construction process. To check the rendering of
a modification, save the application, then click the Preview sub-tab.
Until the web application is published, the changes cannot be seen by the end user.
Creating and configuring a web application

Web applications are created and managed according to the same principle as online surveys.
For more on this, refer to the Advanced user guide.
However, the functional differences are as follows:
Web applications use no archived fields. Data can therefore be stored in database fields
or local variables only.
There are no factory reports on Web applications.
Additional fields are offered, mainly for creating tables and charts:

Charts
You can include charts in Web applications. To do this, select the Add a chart menu, then
select the type of chart to be inserted.
Tables
204 | © Neolane 2010

To add a table, select the type of table from the popup menu.
Overview-type web applications

The Neolane v5 interface uses many web applications to access, manage, and interact with
recipients, deliveries, campaigns, stocks, etc.
They are seen in the interface in the form of dashboards with only one page.

The out-of-the-box web applications are stored in the Administration>Configuration>Web
applications node.
You may also refer to Overview [page 187].
Editing forms
Editing form Web applications for an extranet are characterized by:
A preloading box
In most cases, the data to be displayed must be preloaded. Because the users who access these
forms are identified (via an access control), preloading is not necessarily encrypted.
A save box
Adding pages
Whereas "Overview"-type web applications all have a single page, editing forms can offer a
sequence of pages based on specific criteria (tests, selections, profile of connected operator,
etc.).
The operation of this type of web application is similar to Surveys, but without history management
or field archiving. Users usually access it via a login page where they must identify themselves.
206 | © Neolane 2010

Examples of overview configuration
Recipient view
Here we provide examples on how Web applications are constructed in Neolane.
The overview of recipients is constructed via a Web application. It is accessible via the Neolane
home page, in the Neolane Platform>Profiles and targets section from the Recipients
link:

It is created in a single page containing all the information required to generate it:
The rendering of these elements is as follows:
Default configuration
By default, the recipients table lists the last 200 recipients who were subject to a modification. This
configuration is saved in the recipients web application, in the following table:
208 | © Neolane 2010

The number of profile lines displayed is defined in the Maximum number of lines field
in the Data tab:

The sorting order is indicated in the Sorting sub-tab of the Data tab:
210 | © Neolane 2010

The filtering area above the table (defined in the Filters container) is applied via the
configuration of the Sort sub-tab.
Add columns
You can easily adapt the data offered in this view. To do this, edit the Recipients table and
click the Data tab. You can add or delete columns, change their label, apply special formatting,
etc.
In the following example, the Age and Format columns were added, and the column containing
the account number was re-named.

To add these columns to the table, select the appropriate fields in the Data tab.
Specify the size and, if necessary, modify the labels. Save changes, then click the Preview tab in
web applications to view the rendering.
Warning:
If you use the data from one field several times in a page, you must enter two distinct aliases in the
Alias column.
212 | © Neolane 2010

Personalizing column display
You can personalize the display of data contained in the columns via the Size column in the
output column table:
The values entered in the Size column are the length of the corresponding column.
Input the value 0 for the column to occupy the entire remaining length.
You can merge the data from several fields into one column, as in the example below:
To configure the Last name and first name column, the size of the Last name field must
be set to -1 and the label of the First name field must be changed.

Note:
The Name field must be placed before the First name field in the list of output columns.
You can then group as much information as necessary in a single column. For each one, the size
must be set to -1.
Adding details
By default, when you click a recipient, you access all the data in the recipient's profile in a new
window.
You can add details to be displayed when the user clicks on a recipient, as in the following example:
214 | © Neolane 2010

To do this, select the Columns and additional detail option in the general tab of the recipient
table.
An additional tab lets you configure the data to be displayed. In order to be displayed, this
data must first be loaded. To do this, you must add it in the Data tab.
For example, to display the date of birth and postal address, as in our example, the following
configuration is used:

However, this data must not be visible in the columns; only in the additional details. To do this, select
the appropriate option in the Hidden field column.
In the Additional detail tab, enter the content of the information to be displayed. You can use
existing fields and create additional texts. These texts are defined in the Texts sub-tab and should
be used with the following syntax: $Identifier.
216 | © Neolane 2010

To create a new text, click the Texts sub-tab and the Add icon. Enter the identifier and its
value in the corresponding columns:
This procedure lets you centralize the texts used in the table and manage translations, as for
HTML texts. The texts created in this sub-tab are used again in the integrated Neolane
translation tool, as in the example below:
Save changes and click the Preview tab to view the rendering of the web application. Additional
details are added to each recipient's profile.

Personalizing labels
In our example concerning recipient overview, we have also changed the names of the columns, the
name of the new recipient creation button, and the ToolTip.
To do this, simply access the various objects that make up this web application and change the
default values. For example, for the profile creation button, make the following changes:
218 | © Neolane 2010

Adding an edit link
Once the additional details have been configured, when the user clicks a recipient, it is no
longer the profile, but the additional details which are being edited. For access to the recipients
profile from this view, add an edit link as shown below.
To add this link, edit the Web application in the overall recipient view and select the Recipients
table. In the Additional detail tab, enter the following two lines under the first line:
The Source tab then contains the following information:

Next, create values for the openDesc and openLabel variables. These values are created in the
Texts sub-tab.
Data formatting
Adapting the date format

If you display dates in the columns of the table (date of birth, date of subscription to an information
service, etc), they are automatically formatted in the default format of the console language, i.e.
DD/MM/YYYY for French and MM/DD/YYYY for English.
If a date is used in the additional details, you must enter the formatting rules as in the following
example:
The last part of this formula lets you indicate the date display mode. The possible formats are as
follows:
"%D %B %4Y" for display in 4 November 1998 format,
"%B %2Y" for display in November 98 format.
You can also use the following values:
false to display 04/11/1998,
true to display Wednesday 4 November 1998.
220 | © Neolane 2010

Display a percentage bar
You can add a percentage bar-type object to represent a value graphically. For example, the
quality of a postal address, assessed using a value between 0 and 5, can be displayed as a
percentage in the details of each recipient:
To do this, add the Quality rating field to the loaded data. Select the Hidden field option
to avoid displaying this information in the columns.
Edit the Additional detail tab and add the following line:
Save and click the Preview tab of the web application to view the rendering.
You can also display this percentage bar in the body of the table. For more on this, refer to
Task overview [page 224].

Truncating the content of a column
To manage the length of the data displayed, you can define a maximum size beyond which the
characters will be truncated, as in the example below:
To do this, the formatting formula is as follows:
The value 32 is the maximum number of authorized characters in the Campaign column.
Adding images
Displaying images in the table

You can add images in the columns of the table.
For example, if the age of the recipient is entered, a special icon is added in the line of their profile.
If not, another image will be displayed.
This configuration is obtained via the following formatting formula (obtained via a JavaScript inline
condition):
222 | © Neolane 2010

This formula must be added in the Formatting column of the Age field:
For certain enumeration values, an image is associated by default, e.g. for deliveries or task
statuses. In this case, simply enter the relevant alias in the Alias column to display the label
or image, depending on your requirements:
For the above example, the rendering is as follows:
Adding images in the additional detail

You can also add images in the additional detail. For more on this, refer to Adding an edit link
[page 219].

Task overview
The task overview has a progress percentage bar at the beginning of each line:
To do this, display the progress of the task in the table and add the following parameter:
The size of this field is -1 in order to merge this data with the task label.
For the last formatting parameter, you can choose from the following colours:
blue (default color),
brown,
dkgray,
gray,
green,
red.
Note:
In this example, because the progress is expressed as a percentage, you must use the
bargraphPercent function. The bargraph function, on the other hand, must be used when the
data represented is not expressed as a percentage. It must then be between 0 and 1 to be represented
as a percentage in the table. See the representation of address quality in our example on the recipient
view here: Display a percentage bar [page 221].
Example of an editing form configuration

The task notification form is sent to the operators involved in carrying out the task.
224 | © Neolane 2010

It looks like this:

Its configuration is defined in the Edit task Web application:
226 | © Neolane 2010

The Edit task page contains the information displayed and the input fields. The preloading
box lets you load the data of the task in order to adapt the content of the page.
Once the page has been approved, a test checks that the task is not canceled or finished and
that the data entered in the fields of the page can be saved. The Approval post-processing
script changes the status of the task to Finished when it reaches 100%.

CHAPTER 8
Response management
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Configuring schemas . . . . . . . . . . . . . . . . . . . . . . . 230
Response management with Neolane recipients . . . . . . . . . . . . 230
Response management with a recipient table outside of Neolane . . . . . . 231
Measurement process overload . . . . . . . . . . . . . . . . . . . 232
Introduction
Response management lets you measure transactions from a table, and depending on certain
hypotheses, the reactions of individuals to an offer or a delivery. The aim is to assess the
revenue generated by the action, the profiles of the people who react, the products or services
purchased, etc.
For example, following a delivery promoting an item, we wish to evaluate the revenue generated.
We apply the hypothesis that any recipient who has purchased at least one item in the month
following the triggering of the delivery has reacted to this action. Response management will
determine, based on this hypothesis, which purchase request lines should be assigned to it.
Then, based on this, it will be possible to determine the resulting revenue as the sum of these
lines.
The measurement hypothesis is launched by the operation process workflow (operationMgt).
Each hypothesis represents a separate process executed asynchronously with an execution
status (Being edited, Pending, Finished, Failed, etc.) and controled by a scheduler that manages
Neolane v5.1 - Configuration Guide - Response management | 229

priority constraints, restriction of the number of simultaneous processes, the low activity page and
automatic execution with frequency.
This document is intended for persons responsible for configuring response management. It assumes
a certain amount of knowledge about extending schemas, defining workflows, and SQL programming.
It describes:
How to adapt the standard data model to the specific nature of a transaction table external to
Neolane to the table of individuals. This table of individuals can coincide with the table of available
individuals in Neolane or with a different table.
How to overload the hypothesis measurement process.
Configuring schemas
Application integration is required before using the reaction module, in order to define the various
tables to be measured as well as their relationship with deliveries, offers and individuals.
The out-of-the-box nms:rematch schema contains the reaction log table, i.e. the relation between
individuals, hypothesis and transaction table. This schema shall be used as an inheritance schema
for the reaction logs' final destination table.
The nms:remaMatchRcp schema comes as a standard, it contains the storage of reaction logs for
Neolane recipients (nms:recipient). In order to be used, it will need to be extended to be mapped
to a transaction table (purchases, etc.).
Note:
The transaction table must include links towards individuals. We also highly recommend adding an
event date.
The relationships between the tables concerning response management are presented in Response
management [page 23].
Important:
It is recommended not to modify the standard schemas of the application directly, but to use the
schema extension mechanism. Otherwise, any future upgrades of the application may overwrite the
modified schemas. This could lead to operating malfunctions in Neolane.
Response management with Neolane recipients

In this example, we will integrate a table of purchases in our response management module using
the Neolane recipient table. (nms:recipient).
Extension of nms:remaMatchRcp.
The table of response logs on a recipient is extended to add a link to the purchase table schema.
In the following example, the purchase table is called demo:purchase :
230 | © Neolane 2010

Response management with a recipient table outside of Neolane
In this example, we will integrate a purchase table in our response management module using
a table of individuals other than the recipient table available in Neolane.
Creating a new response log schema derived from the nms:remaMatch schema.
Since the table of individuals is different from the table of Neolane recipients, it is necessary
to create a new schema of the reponse logs based on the nms:remaMatch schema. Then
complete it with the links towards the delivery logs and the purchase table.
In the following example, we will use the demo:broadLogPers schema and the
demo:purchase transaction table:
Modification of the hypothesis form in the nms:remaHypothesis schema.

By default, the list of response logs is visible in the recipient logs. You must therefore
modify the hypothesis form in order to view the new response logs created during the
previous step.
For example:
Neolane v5.1 - Configuration Guide - Response management | 231

Measurement process overload
It is possible to overload SQL processes and update the hypothesis during the execution phase in
order to modify or optimize queries generated automatically or add/overload an indicator on the
hypothesis.
To do this, you need to implement this configuration in JavaScript then enter it in an option.
1 Create a JavaScript code via Administration>Configuration>JavaScript codes.
This code implements the methods of the XtkHypothesisProcess object called during
measurement processing.
The content is as follows:
The iStep parameter contains the measurement processing step. The constants used have the
following functions:
PROCESS_STEP_INSERT_TMP_REMAMATCH: inserts the transaction of the hypothesis context
in the wkRemaMatch_[Hypothesis ID] temporary table.
PROCESS_STEP_INSERT_REMAMATCH: inserts or updates of the response logs in the
NmsRemaMatch[XXX] table.
PROCESS_STEP_COMPUTE_INDICATOR: updating of the hypothesis indicators.
The this.eHypothesis XML function contains the hypothesis definition.
The this.remaHypothesis XML object contains the hypothesis to be updated.
The this.strSql string contains the SQL code generated during the
PROCESS_STEP_INSERT_TMP_REMAMATCH and PROCESS_STEP_INSERT_REMAMATCH stages.
2 Create a Text type option via Administration>Options.
3 Assign it the internal name NmsResponse_JavascriptExt and indicate the name of the
JavaScript code in the Value field.
232 | © Neolane 2010

CHAPTER 9
Offer management
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Calling of the offer engine by an inbound contact . . . . . . . . . . . . . 234
Integration via HTML . . . . . . . . . . . . . . . . . . . . . . 234
Integration via SOAP . . . . . . . . . . . . . . . . . . . . . . 235
Offer management with a recipient table outside of Neolane . . . . . . . . . 236
New recipient offer proposition schema . . . . . . . . . . . . . . . 236
Offer environment configuration . . . . . . . . . . . . . . . . . . 238
Typology rule configuration . . . . . . . . . . . . . . . . . . . . 238
Interaction schema extension . . . . . . . . . . . . . . . . . . . . 238
Introduction
Offer management lets you determine a set of offers to be targeted towards an individual
using business rules.
An offer is linked to an environment containing the definition of the individuals to be targeted,
the Neolane space where all offer propositions are saved and the offer presentation rules. The
environment includes the various communication channels used and the offer categories.
The offer categories group information on offer eligibility, i.e. the targeting criteria and context
specifying the offer's conditions of application based on channel and weighting. At this level
of the tree, it is possible to create personalized content depending on the desired channel.
This chapter deals with using a table of recipients outside of Neolane and on configuring the
search engine for offering and updating one or more offers.
Neolane v5.1 - Configuration Guide - Offer management | 233

Calling of the offer engine by an inbound contact
The integration of the offer management module requires a URL using HTML or SOAP technology.
In both cases, it is possible to present a recipient with a new offer or to update an identified offer.
The URL is as follows:
Integration via HTML

Offer proposition
Add the following parameters to the basic URL to identify the recipient and the number of offers to
which they are entitled.
a=Propose: triggers the offer proposition (mandatory).
n=<EXPECTED_NUMBER_OF_OFFERS>: indicates the number of offers available for the
recipient (mandatory).
t=<PRIMARY_KEY_OF_THE_TARGET>: ID coinciding with the recipient (mandatory).
Example:
In response to the query contained in the URL, the various offers are returned in the form of an
HTML table.
Note:
Context parameters are not supported and cannot be integrated into the URL.
Only spaces with a web representation are supported.
We recommend using a SOAP service to sidestep these limitations. Refer to Integration via SOAP
[page 235].
Updating an offer proposition

The offer proposition is updated using the following parameters added to the base URL:
a=UpdateStatus: indicates offer proposition updating.
p=<PRIMARY_KEY_OF_THE_PROPOSITION>: proposition ID (mandatory).
st=<NEW_STATUS_OF_THE_PROPOSITION>: indicates the new status of the updated
offer proposition (mandatory).
r=<REDIRECT_URL>: Redirecting URL (optional).
The response to this query is the display of an empty HTML page or a redirecting URL.
234 | © Neolane 2010

Integration via SOAP
The SOAP web services provided for offer management are different from those usually used
in Neolane. They can be accessed via the interaction URL described below and let you suggest
or update offers for a given contact.
Offer proposition
For an offer proposition via SOAP, add the nms:proposition#Propose command followed
by the following parameters:
targetId: string type, primary key of the recipient (can be a composite key).
maxCount: string type, indicates the number of offer propositions for the contact.
context: XML element, lets you add context information in the schema of the location. If
the schema used is nms:interaction, <empty/> should be added.
In response to the query, the SOAP service will return the following parameters:
interactionId: ID of the interaction.
propositions: XML element, contains the list of propositions, each with their own ID and
HTML representation.
Offer update
Add the nms:interaction#UpdateStatus command to the URL, followed by these parameters:
propositions: XML element, contains the list of propositions given in output during an
offer proposition. Refer to Offer proposition [page 235].
status: string type, indicates the new status of the offer.
context: XML element, lets you add context information on the offer in the location schema.
If the schema used is nms:interaction, <empty/> should be added.
Example using a SOAP call

Here is an example of code for a SOAP call.

Offer management with a recipient table outside of Neolane
To use the offer management module with a table of individuals other than the recipient table available
in Neolane, you need to create a new proposition schema and redefine the offer environment as well
as the related typology rules.
New recipient offer proposition schema

Since the individuals table is different from the Neolane recipients table, you need to create a new
offer proposition schema based on the nms:proposition schema.
236 | © Neolane 2010

In the following example, the created schema is nms:propositionProfil, the recipient table
cus:profil and the recipient delivery logs cus:broadLogProfile.

Offer environment configuration
When defining the environment of marketing offers, you need to indicate the targeting schema and
the storage schema depending on the individuals table used and the offer proposition schema created
previously.
Typology rule configuration

If you've created typology rules for selecting offers for a given contact, you also need to modify them
so that they comply with the new offer proposition schema.
Refer to the "Campaign typologies" section in the User guide.
Interaction schema extension

In the case of an inbound contact (call center or web site), the most relevant offers are suggested
to a given customer using a set of eligibility rules. To enrich the application contexts of your offers,
extend the nms:interaction schema using the method described in Extending schemas [page 37].
238 | © Neolane 2010

To add a new interaction context, insert as many attribute elements as necessary in the
schema.
Enter your new interaction schema in the offer space.

You can then use the attributes previously created when defining the eligibility context definition.
When configuring SOAP calls, insert the context XML element to reference context information
added in the interaction schema. For further information, refer to Integration via SOAP [page 235].
240 | © Neolane 2010

CHAPTER 10
Setting up Web tracking
Table of Contents
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Web tracking tag: definition . . . . . . . . . . . . . . . . . . . . 242
Format of the data to be sent . . . . . . . . . . . . . . . . . . . 242
Data transmission methods . . . . . . . . . . . . . . . . . . . . 244
Setup stages . . . . . . . . . . . . . . . . . . . . . . . . . 244
Additional web tracking parameters . . . . . . . . . . . . . . . . . . 245
Definition of parameters . . . . . . . . . . . . . . . . . . . . . 245
Redirection server configuration . . . . . . . . . . . . . . . . . . 245
Creating web tracking tags . . . . . . . . . . . . . . . . . . . . . 246
Defining the URLs to be tracked in the application . . . . . . . . . . . . 247
On-the-fly creation of URLs to be tracked . . . . . . . . . . . . . . . 247
Inserting tags in your site . . . . . . . . . . . . . . . . . . . . . 248
Simple method . . . . . . . . . . . . . . . . . . . . . . . . 248
Optimum method . . . . . . . . . . . . . . . . . . . . . . . 250
Collecting all visits to a site . . . . . . . . . . . . . . . . . . . . . 252
Server configuration . . . . . . . . . . . . . . . . . . . . . . 253
Configuring a default matching campaign . . . . . . . . . . . . . . . 253
In addition to standard tracking that shows the behavior of an internet user clicking on a link
in an e-mail message, the Neolane platform lets you collect information on how internet users
browse your web site. This data collection is performed by the web tracking module.
Neolane v5.1 - Configuration Guide - Setting up Web tracking | 241

Overview
When an internet user clicks a tracked link in an e-mail from a given delivery, the redirection server
contacted deposits a temporary cookie containing the recipient identifier and delivery identifier.
The web client then sends this cookie to the server each time the user visits a page containing a web
tracking tag. This continues throughout the session, i.e. until the web client is closed.
The redirection server collects the following data in this way:
URL of the page viewed, via an identifier sent as a parameter,
the delivery from which the web page was visited, via the session cookie,
identifier of the internet user who clicked, via the session cookie,
additional information such as the business volume generated.
The following diagram shows the stages of the dialog between the client and the various servers.
Figure 10.1. Client/web server/redirection server exchanges
Web tracking tag: definition

A web tracking tag is simply a URL constructed with the appropriate parameters, sent to the redirection
server via an HTTP query.
Format of the data to be sent

The format of a web-tracking URL is as follows:
242 | © Neolane 2010

Note:
The random number added to the URL avoids problems caused by browsers caching web
pages.
The following table gives a list of special parameters supported by the redirection server.
Name Type Description

ID Session cook- Delivery identifier and recipient identifier.
ie
uuid230 Permanent Recipient identifier (useful if session cookie
cookie is absent).
tagid URL paramet- Identifier of tracked web page: this is the
er only mandatory parameter.
jobid URL paramet- Delivery identifier to be used if there is no
er session cookie. This value is to be expressed
in hexadecimal.
rcpid URL paramet- Parameter used to identify the internet user.
er The format of this parameter is
"name=value", where the name is a field of
the recipient schema. This parameter takes
priority over the identifier contained in the
session cookie.
A few web tracking URLs

Visit to a 'home' identifier page
Collecting business volume data
Specifying a field to find the recipient
A recipient whose account number is 10 is sent to the home page.

Using a default delivery
A recipient is sent to the home page. This information will be stored in the delivery with
identifier 230 (i.e. e6 in base 16) unless a session cookie containing a delivery identifier is
sent with this query.
Note:
All values sent to the redirection server via URL parameters must be URL encoded. In the
examples given, note that the characters '=' and '|' are encoded as '%3D' and '%7C'
respectively.

Data transmission methods
The following methods are possible:
Inserting the URL in the attribute of an HTML tag incorporated in the web page
you wish to track.
Direct call to the redirection server when the web page you wish to track is generated.
Setup stages
The basic principle is the insertion of web tracking tags in certain pages of your web site.
There are two types of tags:
WEB: this tag tells you if the page has been visited,
TRANSACTION: operates like a Web tag, but with the possibility of adding information on the
business volume generated, for example (transaction amount, number of items purchased, etc.).
Apply the following steps to set up these tags:
1 Identify the pages you wish to track and determine their type (WEB or TRANSACTION).
2 Determine which additional information you wish to collect, and extend the nms:webTrackingLog
schema with the description of this information. By default, this schema can store the transaction
amounts and number of items per transaction.
3 Creating the web tracking tags. There are two ways of doing this:
Insert the URLs corresponding to these pages in your Neolane platform, then generate and
extract the associated web-tracking tags (from the Campaign execution>Resources>Web
tracking tags node of the client console).
Create the web-tracking tags yourself in "on-the-fly creation" mode: the URLs corresponding
to these pages will be automatically inserted in your Neolane platform.
4 Add these tags statically or dynamically in the pages you wish to track.
Note:
All WEB-type tags can be added as they are to the pages of your site. TRANSACTION tags must
be modified or added dynamically in order to contain the additional information (amount, items,
etc.).
Example:
244 | © Neolane 2010

Additional web tracking parameters
Definition of parameters
Your Neolane platform offers two TRANSACTION-type web-tracking parameters as a standard:
amount: represents the amount of a transaction,
article: represents the number of items in a transaction.
These parameters are defined in the nms:webTrackingLog schema, and are some of the
indicators seen in reporting.
To define additional parameters, you must extend this schema. for further information, refer
to Extending schemas [page 37].
Example:
You can display the values of these parameters by configuring the tracking log list (of a delivery
or recipient).
Redirection server configuration

In the server configuration, you can define the maximum number of characters to be taken
into account for your web tracking parameters.
Warning:
The correct calculation of the number of characters to be taken into account is important for
optimizing the web tracking performance of your platform.
To do this, modify the webTrackingParamSize attribute of the element

in the file. This file is saved in the subdirectory of the Neolane
installation directory.
Example:
The default value is 32 characters. This value lets you take into account the and
("amount=xxxxxxxx&article=xxxxxxxx") standard parameters.

By taking into account both parameters (size of name + size of value) indicated in the above extension
schema example, you can modify the configuration to take 60 characters into account
("amount=xxxxxxxx&article=xxxxxxxx&mode=xxxxxxxxxx&code=xxxxx").
When the configuration has been modified, you must:

Stop the web server that hosts the redirection module (Apache, IIS, etc.),
Stop the Neolane server: in Windows,
in Linux,
In Linux, delete the shared memory segments using the command,
Restart the Neolane server: in Windows,
in Linux,
Restart the web server.
Example: taking into account of the configuration under Linux.
Creating web tracking tags

Each page of the site that you wish to track must be referenced in your Neolane platform. This
referencing can be performed in two ways:
1 Manual definition of URLs to be tracked,
2 On-the-fly creation of URLs to be tracked.
246 | © Neolane 2010

Defining the URLs to be tracked in the application
This method lets you manually define the pages to be tracked and then generate an example
of the associated web tracking tag. This operation is defined in the Campaign
execution>Resources>Web tracking tags node of the client console.
To generate the HTML code to be inserted in the page:

Enter the label of the tag: it will be shown in the tracking logs,
Indicate the source URL: this field is for information purposes and lets you indicate the
tracked page (optional),
If needed, enter a validity period,
Click Generate HTML code.
Then copy the generated code and paste it into the page to be tracked.
On-the-fly creation of URLs to be tracked

You can create the web tracking URLs on the fly by adding information to the value of the
tagid parameter:
Type of page tracked: 'w' for WEB or 't' for TRANSACTION,
The internal name of the folder where the URL must be created.

These two pieces of information must be concatenated with the identifier of the tracked page by
adding the character '|':
Warning:
Remember to encode the value of the tagid parameter when it is used as a URL parameter.
Example: creation of a transaction-type web tracking URL.
Inserting tags in your site
Simple method
This method consists of sending an HTTP call to the redirection server by inserting an HTML
tag in the HTML source code of the web page you wish to track.
Warning:
This method uses the cookies sent by the web browser to identify the recipient, and is not 100%
reliable.
Example:
The inserted tag contacts the redirection server.
Figure 10.2. Client/redirection server/web server exchanges
When you define a page to be tracked in the console, you can generate a sample web tracking tag
to copy and paste into the source code of your web page.
248 | © Neolane 2010

When you use TRANSACTION-type tags, however, you must modify the sample tag using
JavaScript in order to insert the transaction information (amount, number of items) and any
information defined by an extension schema.
Static insertion of tags

To perform static tag insertion, simply copy and paste the tags generated by the console or
constructed manually into the source of your web page.
Example: insertion of a web tracking tag on a page displaying a form.
Insertion of a TRANSACTION-type web tracking tag in the confirmation page ("amount.html").
Dynamic generation of web tracking tags

When your web pages are generated dynamically, you can add the web tracking tag at page
generation time.

Example: Web tracking added to JSPs.
Optimum method
If you wish to control the information sent to the redirection server, the most reliable way is to
perform the HTTP query synchronously yourself using a page generating language.
250 | © Neolane 2010

The URL you construct must obey the syntax rules defined in Web tracking tag: definition
[page 242].
Figure 10.3. Client/redirection server/web server exchanges
Note:
Redirection and web tracking use cookies, and it is important that the web server performing
the synchronous HTTP call be in the same domain as the redirection server. The various HTTP
exchanges must convey the 'id', 'uuid', and 'uuid230' cookies.
Example: Dynamic generation in Java, with recipient authentication using their account
number.

Collecting all visits to a site
The web tracking module supplied by Neolane lets you collect the visits to certain pages of the site
performed by a recipient in the context of site tracking following a click in a message.
You can, however, configure your platform so that it collects all visits to pages with a web tracking
tag by a user known to the platform.
A user known to the platform is a recipient who has already been targeted by a delivery and who
has clicked in a received message at least once. A permanent cookie is used to identify this recipient.
Warning:
The Neolane platform is not intended for use as a web site tracking tool beyond the context of visiting
the site following a click in a message. When this option is enabled, it can cause very high use of
resources on the machines hosting your servers (redirection, application, and database). You are
advised to ensure that your hardware architecture can support this load, and to avoid placing web
tracking tags in the most frequently visited pages, such as the home page.
252 | © Neolane 2010

Server configuration
The servers are configured by overloading certain elements of the serverConf.xml file. These
files are saved in the conf subdirectory of the Neolane installation directory.
Redirection server
For the redirection server, set the trackWebVisitors attribute of the element
to true.
Application server
For the application server, set the logWebVisitors attribute of the element to
true.
Configuring a default matching campaign

To view tracking information via your client console, you must:
Create a dummy delivery,
Enter the code of this delivery in the NmsTracking_WebVisitorDelivery option.
To do this, you must import the trackVisitors datapackage located in the
subdirectory of your platform's installation
directory.
All site tracking information not directly subsequent to a click in an e-mail can be viewed in
the dummy delivery created.

CHAPTER 11
Content management
Table of Contents
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Advantages . . . . . . . . . . . . . . . . . . . . . . . . . 256
Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 256
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Implementation . . . . . . . . . . . . . . . . . . . . . . . . 257
Content configuration . . . . . . . . . . . . . . . . . . . . . . 260
Data schemas . . . . . . . . . . . . . . . . . . . . . . . . . 261
Identification of a schema . . . . . . . . . . . . . . . . . . . . 262
Schema structure . . . . . . . . . . . . . . . . . . . . . . . 263
Categorizing data by type . . . . . . . . . . . . . . . . . . . . 264
Properties . . . . . . . . . . . . . . . . . . . . . . . . . 264
Collection elements . . . . . . . . . . . . . . . . . . . . . . 266
Element referencing . . . . . . . . . . . . . . . . . . . . . . 267
Compute string . . . . . . . . . . . . . . . . . . . . . . . . 267
Edit schemas . . . . . . . . . . . . . . . . . . . . . . . . 268
Input forms . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Identifying a form . . . . . . . . . . . . . . . . . . . . . . . 269
Form structure . . . . . . . . . . . . . . . . . . . . . . . . 269
Formatting . . . . . . . . . . . . . . . . . . . . . . . . . 270
List type controls . . . . . . . . . . . . . . . . . . . . . . . 272
Containers . . . . . . . . . . . . . . . . . . . . . . . . . 275
Editing forms . . . . . . . . . . . . . . . . . . . . . . . . 278
Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Stylesheets . . . . . . . . . . . . . . . . . . . . . . . . . 279
JavaScript templates . . . . . . . . . . . . . . . . . . . . . . 284
Neolane v5.1 - Configuration Guide - Content management | 255

Publication template . . . . . . . . . . . . . . . . . . . . . . . . . 289
Identification of a publication template . . . . . . . . . . . . . . . . . . 289
Configuring the template . . . . . . . . . . . . . . . . . . . . . . . 290
Purpose
Warning:
The content management module (Neolane Content Manager) is an optional Neolane module.
The content management module is used to create recurrent newsletters (frequent delivery with a
defined graphical charter) or web sites (special event mini-sites, marketing campaigns).
It can help you to create, validate, and publish your messages.
Content management incorporates working group, workflow and content aggregation functionality.
This allows a message to be formatted automatically (e-mail, mail, SMS, MMS, fax, call center, web,
etc.).
Advantages
Content management provides the following advantages:
Structured message editing via input interfaces,
Separation of data content and how it is presented (generated in XML format),
Generating documents in multiple formats (html, txt, XML, etc.) from stylesheets to guarantee
compliance with graphical charters,
Recovery and automatic aggregation of external content flows,
Collaboration with workflow for data validation and checking.
Constraints
This mode of content creation does however involve a few constraints; including in particular:
Restricted freedom concerning the final document design,
The analysis of requirements must be rigorous so that end users will not be inconvenienced by
a missing function.
Overview
A data model, also known as a publication template, is defined for each content.
A content block is structured in an XML document for data storage. An edit interface is used to input
the content from the Neolane client console or via a web browser. The content can also be entered
automatically via the capture of XML flow or data aggregated in a database.
256 | © Neolane 2010

The combination of the XML document and the XSL stylesheets automatically generates the
projection of the publication template in the various formats (HTML, text, etc.).
Implementation
To create content management in Neolane, at least the following elements must be configured:
1 A data schema, see Data schemas [page 261],
2 An input form, see Input forms [page 268],
3 A content building template (JavaScript template or XSL), see Formatting [page 279],
4 A publication template that links the first three elements, see Publication template [page 289].
You may then create content based on this publication template. To do this select the Content
management>Content node of the tree and right-click. Select Properties.

Select the publication templates that will be active for this folder.
You can now create new content using the New button above the content list.
258 | © Neolane 2010

You can also create content using content management in the deliveries. To do this, you need
to reference a publication template via the Advanced tab of the delivery properties.

An additional tab is added to the delivery wizard in order to define the content via the content
management form.
Content configuration
You can access the content management tree via the Content management node of the Neolane
client console.
260 | © Neolane 2010

The following resources are required for content configuration:
Data schemas: description of XML content structure. See Data schemas [page 261].
Data entry forms: construction of data entry screens. See Input forms [page 268].
Images: images used in data entry forms. See Image management [page 281] and Image
management [page 287].
Stylesheets: formatting of output documents using XSLT language. See Formatting
[page 279].
JavaScript templates: formatting of output documents using JavaScript language. See
Publication template [page 289].
JavaScript codes: JavaScript codes for data aggregation. See "Link aggregation" in the
Advanced user guide.
Publication templates: definition of publication templates. See Publication template
[page 289].
Contents: content instances to be published. For more on this, see "Creating and editing
content" in the Advanced user guide.
Data schemas
A data schema is an XML document associated with content. It describes the XML structure
of the data of this content.
To create a data schema, follow these steps:
1 Click the New icon located above the list of data schemas.
2 Select the Create a schema option for content management, then click Next.

3 Enter the name and label of the schema into the coinciding fields. You can add a description and
associate a specific image if necessary.
Click Next to validate.

4 Enter the content of the schema in the Schema editing window.
For more on this, refer to Edit schemas [page 268].
Click Save to create the data schema.
Identification of a schema
A data schema is identified by its name and its namespace.
A namespace lets you group a set of schemas by interest. For example, the "cus" namespace is used
for customer-specific configuration.
Warning:
As a standard, the name of the namespace must be concise and contain only authorized characters
in accordance with XML naming rules.
The following namespaces are reserved for descriptions of the system entities required for the
operation of the Neolane application:
xtk: concerning platform system data,
nl: concerning global use of the application,
nms: concerning delivery (recipient, delivery, tracking, etc.),
ncm: concerning content management.
The identification key of a schema is a string formed by the namespace and the name separated by
a colon; for example: cus:book.
262 | © Neolane 2010

Schema structure
The XML document of a data schema must contain the <srcSchema> root element with the
name and namespace attributes in order to populate the schema name and its namespace.
To illustrate the structure of a data schema, we will start from the following XML content:
With its corresponding data schema:
The point of entry of the schema is its main element. It is easy to identify because it has the
same name as the schema, and it must be the child of the root element. The description of
the content begins with this element.
In our example, the main element is represented by the following line:
The template attribute entered in the main element lets you extend the schema with generic
properties to all content definitions such as name, creation date, author, associated string,
etc.
These properties are described in the ncm:content schema.
Note:
The presence of the xmlChildren attribute indicates that the data structure entered via the
main element is stored in an XML document of the content instance.
The <attribute> and <element> elements following the main element let you define the
location and name of data in the XML structure.
The following rules must be applied:

Each <element> and <attribute> element must be identified by its name via the name
attribute.
Warning:
The name of the element must be concise and should include only authorized characters in
compliance with XML naming rules.
Only an <element> can contain an <attribute> or <element> element in the XML structure.
An <attribute> element must have a unique name in an <element>.
It is recommended to use an <element> for a multiple-line data string.
Categorizing data by type

The following data types are supported in a schema:
string: character string whose size can be specified using the length attribute (optional; default
value: "255"),
boolean: Boolean field,
byte, short, long: integers (1 byte, 2 bytes, 4 bytes),
double: double-precision floating point number,
date, datetime: dates and dates + times,
html: value specifying HTML code.
The data type is specified via the type attribute on the <attribute> and <element> elements.
"string" is the default type, except if the element contains child elements. In that case, it is used only
to structure the elements hierarchically (<chapter> element in our example).
Here is the example schema with the types filled in:
Properties
Various properties can be used to enrich the <element> and <attribute> elements of the data
schema.
The main properties used in content management are as follows:
label: short description,
desc: long description,
264 | © Neolane 2010

default: expression returning a default value on content creation. The most commonly
used expressions are:
Current date:
Fixed string:
Counter:
In this example, the default value is constructed by concatenation of a chain and by
calling the CounterValue function with a free counter name. The number returned is
incremented by one on each insertion.
Note:
In the client console, the Administration>Counters node is used to manage the
counters.
userEnum: free enumeration to store and display the values entered via this field. The
syntax is as follows:
The name of the enumeration is a free choice and can be shared with other fields.
In the Neolane client console, these values are displayed in a drop-down list from the input
form:
Note:
In the client console, enumerations are managed using the
Administration>Enumerations node.
enum: fixed enumeration used when the list of possible values is known in advance.
The "enum" attribute refers to the definition of an enumeration class entered in the schema
outside the main element.
Enumerations let the user select a value from a drop-down list instead of entering it in a
classic input field:
Example of an enumeration declaration in the data schema:

An enumeration is declared outside the main element via the <enumeration> element.
The enumeration properties are as follows:
baseType: type of data associated with the values,
label: description of the enumeration,
name: name of the enumeration,
default: default value of the enumeration.
The enumeration values are declared in the <value> element with the following attributes:
name: name of the value stored internally,
label: label displayed via the graphical interface.
Here is our example schema with the properties filled in:
Collection elements
A collection is a list of elements with the same name and at the same hierarchical level.
The unbound attribute with the value "true" lets you populate a collection element.
In our example, the <chapter> and <page> elements are collection elements. The "unbound"
attribute must therefore be added to the definition of these elements:
266 | © Neolane 2010

Note:
The presence of the ordered="true" attribute lets you order the collection elements inserted.
Element referencing
Element referencing is used a great deal in content schemas. It enables you to factorize the
definition of an <element> element so that it can be referenced on other elements with the
same structure.
The ref attribute on the element to be referenced must be completed with the path (XPath)
of the reference element.
Example: adding of an Appendix section with the same structure as the <chapter> element
of our example schema.
The chapter structure is moved to the element with the name "section" outside the main
element. The chapter and section reference the "section" element.
Compute string
A Compute string is an XPath expression used to construct a string representing a content
instance.
The Compute string of a content schema must be:
Here is our example schema with its Compute string:

Edit schemas
The edit field lets you input the XML content of the source schema:
The preview generates the extended schema. For further information about extended schemas, refer
to Extending schemas [page 37].
When the source schema is saved, extended schema generation is launched automatically.
Note:
The Name edit control lets you enter the key of the schema, consisting of the name and namespace.
The name and namespace attributes of the schema root element are automatically updated in the
XML edit field of the schema.
Input forms
An input form lets you edit a content instance via an input interface from the Neolane client console.
268 | © Neolane 2010

The description of a form is a structured XML document that observes the grammar of the
"xtk:form" form schema.
Identifying a form
An input form is identified by its name and namespace, just like data schemas.
The identification key of a form is a string formed by the namespace and the name separated
by a colon; for example: cus:book.
Form structure
The XML document of an input form must contain the <form> root element with the name
and namespace attributes to populate the form name and its namespace, respectively.
By default, a form is associated with the data schema that has the same name and namespace.
To associate a form with a different name, enter the schema key in the entity-schema
attribute of the <form> element.
To illustrate the structure of an input form, we describe an interface based on our example
schema "cus:book":
This is the corresponding input form:
The description of the edit elements begins with the <form> root element.
An edit control is entered in an <input> element with the xpath attribute containing the
path of the field in its schema.

Note:
Reminder concerning XPath syntax:
The XPath language is used in Neolane to reference an element or attribute belonging to a data
schema.
XPath is a syntax that lets you locate a node in the tree of an XML document.
Elements are designated by their name, and attributes are designated by their name preceded by
the character "@".
Examples:
: selects the attribute with the name "date"
: selects the "title" attribute under the <chapter> element
: selects the date from the parent element of the current element.
The edit control automatically adapts to the corresponding data type and uses the label defined in
the schema.
By default, each field is displayed on one line and occupies all of the available space, depending on
the type of data.
Important:
The input form must reference a type="contentForm" attribute on the <form> element to
automatically add the frame required for content to be input.
Note:
By adding the label attribute to the <input> element, you can overload the label defined in its data
schema; for example:
Formatting
The arrangement of the controls relative to each other looks like the arrangement used in HTML
tables, with the possibility of dividing a control into several columns, of interlacing elements, or of
specifying the occupation of available space. Bear in mind, however, that formatting authorizes the
distribution of proportions only; you cannot specify fixed dimensions for an object.
Example: we return to the previous example, displaying the controls in two columns:
270 | © Neolane 2010

The <container> element with the colcount attribute lets you force the display of child
controls onto two columns.
Note:
The <static> element occupies an empty area in a column.
The colspan attribute on a control extends the control by the number of columns indicated
as its value:
Note:
The <static> element was removed because the "Language" control occupies all columns.
The type="frame" attribute adds a frame around the child controls, with the label indicated
in the label attribute:

A <static> element can be used to add formatting to the input form:
A separator bar with a label was added with a separator-type <static> element.
The <static> elements also let you display help text in the form with the help type.
Note:
The "colcount" attribute was added to the <form> element to force the display of the child controls
in two columns.
List type controls

To edit a collection element, you must use a list type control.
272 | © Neolane 2010

Column list
This control displays an editable column list with a toolbar containing Add and Delete buttons.
The list control must be filled in with the type="list" attribute, and the path of the list must
refer to the collection element.
The columns are declared by the child <input> elements of the list.
Note:
The up and down ordering arrows are added automatically when the ordered="true" attribute
is completed for the collection element in the data schema.
By default, the toolbar buttons are aligned vertically. They can also be aligned horizontally:
The toolbarCaption attribute forces horizontal alignment of the toolbar and fills in the title
above the list.
Note:
For the collection element label not to be displayed to the left of the control, add the
nolabel="true" attribute.

Zoom in a list
The insertion and editing of list data can be performed in a separate edit form.
Edit forms within lists are used in the following cases:
For ease of information input,
Presence of a multiple-line control,
The columns in the list contain only the main fields and the form displays all the fields of the
collection element.
The definition of the edit form is specified via the <form> element under the list element. Its
structure is identical to the structure of an input form.
A Detail button is automatically added when the zoom="true" attribute is entered in the list
definition. This lets you open the edit form on the selected line.
Note:
Adding the zoomOnAdd="true" attribute forces the edit form to be called on insertion of an element
of the list.
274 | © Neolane 2010

Tab list
This list presents the editing of collection elements in the form of tabs.
The list control must be filled in with the type="notebooklist" attribute, and the path of the
list must refer to the collection element.
The title of the tab contains the value of the data entered via the xpath-label attribute.
The edit controls must be declared under a <container> element that is a child of the list
control.
Use the toolbar buttons to add or delete list elements.
Note:
The left and right ordering arrows are added automatically when the ordered="true" attribute
is populated for the collection element in the data schema.
Containers
Containers let you group a set of controls. They exist via the <container> element. They
have already been used to format controls in several columns and for the control of the tab
list.
They are also used to simplify the referencing of controls with the xpath attribute. Control
referencing is then relative to the parent <container> element.
Example of a container without "xpath":

Adding the "xpath" on the "chapter" element:
Types of containers
Containers are used to construct complex controls using a set of fields formatted in pages.
Tab container
A tab container formats data in pages that are accessible from tabs.
The main container is defined with the type="notebook" attribute. Tabs are declared in the child
containers, and the label of the tabs is entered via the label attribute.
276 | © Neolane 2010

Note:
The style="down|up (by default)" property forces the positioning of the tab labels below
or above the control. This property is optional.
Icon list
This container displays a vertical iconbox used to select pages.
The main container is defined with the type="iconbox" attribute. The pages associated with
the icons are declared in the child containers. The label of the icons is entered via the label
attribute.
An image can be displayed for each page with the img="<image>" attribute, where
<image> is the name of an image corresponding to its key constructed with the name and
namespace (e.g. "ncm:article.png"). Images are accessible via the Administration >
Configuration > Images node.
Visibility container
You can mask a set of controls via a dynamic condition.
This example illustrates the visibility of controls on the value of the "language" field:

A visibility container is defined with the type="visibleGroup" attribute. The visibleIf attribute
contains the visibility condition.
Examples of condition syntax:
: tests equality on string-type data. The comparison value must
be in quotation marks.
: condition on a numerical value.
: test on Boolean fields.
Activation container
This container lets you enable or disable a set of data via a dynamic condition. Disabling a control
makes it non-editable. The following example illustrates the enabling of controls via the value of the
"language" field:
An activation container is defined with the type="enabledGroup" attribute. The enabledIf attribute
contains the enabling condition.
Editing forms
The edit zone lets you enter the XML content of the input form:
278 | © Neolane 2010

The Preview tab lets you view the input form:
Formatting
Stylesheets
The XSLT language lets you transform an XML document into another output document. This
transformation is described in XML in a document called a stylesheet.
According to the output method of the stylesheet, the resulting document can be generated
in HTML, plain text, or another XML tree.
Identifying a stylesheet
A stylesheet is identified by its name and namespace, just like schemas and forms. It is,
however, recommended that you add the .xsl extension to the name of the stylesheet.
The identification key of a stylesheet is a string formed by the namespace and the name
separated by a colon; for example: cus:book.xsl.
Structure of a stylesheet
Example of an HTML formatting stylesheet based on the example schema "cus:book":

A stylesheet is an XML document that obeys the following rules:
the values of attributes are between quotation marks,
an element must have an opening and a closing marker,
replace the '<' or '&' characters with the '<' or '&' entities,
each XSL element must use the namespace.
A stylesheet must start with the XSL root element marker and end with the
marker. The XSL namespace must be defined in the opening marker as
follows:
The element specifies the format of the document generated. Specify the desired
set of characters and the output format.
The following instructions describe the configuration of the stylesheet for the formatting of the output
document.
By default, the XSLT processor seeks the that applies to the root or main node of the
input XML document. The construction of the output document begins with this .
In our example, an HTML page is generated from the "cus:book" schema by displaying the name of
the book and the list of chapters.
For more information on the XSLT language, refer to an XSLT reference document.
280 | © Neolane 2010

Displaying HTML/XML
To display an "html" field, use the option from the
directive. This lets you avoid replacing characters with their XML entity (for
example < with <).
The directive with the option lets you
insert JavaScript tags for personalization fields or conditional tests.
Examples:
Displaying the content of an "html"-type field:
Insert the personalization field :
Add the conditional test :
Image management
The images entered in the stylesheet can be referenced with an absolute or relative reference.
Relative referencing lets you enter the URL of the server containing the images in the
NcmRessourcesDir and NcmRessourcesDirPreview options. These options contain the
location of images for publication and preview in the Neolane client console.
Both options are accessible in the option management screen in the Administration>Options
folder.
Example:
NcmResourcesDir = "http://server/images/"
NcmResourcesDirPreview = "x:/images/"
During stylesheet processing, the _resPath attribute on the main element of the input XML
document is automatically filled in with one or other of the options, according to the context
(preview or publication).
Example of initializing a variable with the content of the image location option and its use with
an image:
Note:
We recommend declaring a variable containing the reference of the server where the images
are stored ("resPath" in our example).

Date formatting
In the input XML document, dates are stored in internal XML format: (for
example 2009/10/01 12:23:30).
There is no standard date management function in XSLT syntax. To display a date in the desired
format, Neolane provides the external function . This function takes as its input the
content of the date and a string specifying the output format with the following syntax:
Examples:
To display the date in the 01/10/2009 format:
To display the date in the July 2009 format:
Including stylesheets
It is possible to build up a library of templates or variables to be shared among several stylesheets.
The "longMonth" , presented above, is a typical example of the advantage of locating a
template remotely in a stylesheet so that it can be reused later.
The <xsl:include> directive indicates the name of the stylesheet to be included in the document.
Example: including the "common.xsl" style sheet.
282 | © Neolane 2010

Note:
The name of the namespace must not be entered in the reference of the stylesheet to include.
As a standard, this stylesheet is created with the user namespace.
Editing a stylesheet
The edit zone lets you populate the content of the stylesheet:

To generate a preview of the output document at any time, select a content instance and the format
(HTML, Text, XML), and then click Generate:
Note:
There is no need to save changes in the stylesheet to view the output document preview.
JavaScript templates
A JavaScript template is an HTML or text document that includes JavaScript code. It is constructed
in the same way as an e-mail content in a delivery action.
Identification of a JavaScript template

A JavaScript template is identified by its name and namespace just like schemas and forms. It is,
however, recommended to add the .js option to the template name.
Structure of a JavaScript template

Example of a JavaScript HTML formatting template based on the "cus:book" schema:
284 | © Neolane 2010

The various JavaScript directives appear in the following form:
Merge fields: displays the content of the data with the syntax where
<source> is the source field of the data to be displayed.
Instruction blocks: executes a series of JavaScript instructions included between the <%
and %> tags.
The content object represents the main element of the input XML document.
In our example, the following line displays the content of the name of the book:
The following code iterates on the <chapter> collection element:
The attributes and elements of the content are represented as JavaScript objects and respect
the structure of the source document.
Example:
: retrieves the value of the "name" attribute of the main element
: identical to the syntax
: returns the number of elements on the <chapter> collection
element
: retrieves the name of the first <chapter> element
: returns the name of the <chapter> element
: returns the name of the parent element of <chapter>
Important:
Because the '-' character is reserved in the JavaScript language, the recovery of the value of
any attribute or element containing this character must be carried out via the ['<field>'] syntax.
For example: content.@['offer-id'].
All the power of a programming language (variables, loops, conditional tests, functions, etc. )
is available to construct the output document. SOAP APIs are accessible to enrich the output
document.
Examples:
Conditional test:
Function call:

Declarations and variable call:
Retrieval and display of a recipient name with static methods:
Recovery and display of a recipient name with non-static methods:
286 | © Neolane 2010

Image management
The images entered in the HTML output document can be referenced with absolute or relative
references.
Relative referencing populates the URL of the server containing the images in the
NcmResourcesDir and NcmResourcesDirPreview options. These options contain the
location of the images for publication and preview in the Neolane client console.
These two options are accessible via the option management screen in the
Administration/Options folder.
Example:
NcmResourcesDir = "http://server/images/"
NcmResourcesDirPreview = "x:/images/"
When the stylesheet is being processed, depending on the context (preview or publication),
the _resPath attribute on the main element of the XML input is automatically filled in with
one of the two options.
Example of use of the image placement option and its use with an image:
Date formatting
In the XML input document, the dates are stored in internal XML format:
(example 2009/10/01 12:23:30).
To display a date in the desired format, Neolane provides the function that takes
as input the content of the date and a string specifying the output format with the following
syntax:
Examples:
Display the date in the 31/10/2009 format:
Display the date in the July 2009 format:

Including a JavaScript template
You can constitute a library of functions or variables for later use. To do this, import the JavaScript
template with the function.
Example: importing the common.jsp template.
Editing a JavaScript template

The edit zone lets you populate the content of the JavaScript template:
Note:
The associated data model schema must be populated for the initialization of JavaScript objects.
288 | © Neolane 2010

To generate the preview of the output document at any time, select a content and an output
format (HTML, Text, XML), then click Generate:
Note:
It is not necessary to save the changes in order to preview the output document.
Publication template
The publication template is the identity card of the content to be published. It references the
resources used in the publication process, i.e.:
the data schema,
the input form,
the transformation templates for each output document.
Identification of a publication template

A publication template is identified by its name and namespace.
The identification key of a stylesheet is a string made up of the namespace and the name
separated by a colon; for example: cus:book.
Note:
In practice, it is recommended to use the same key for the schema, the form, and the
publication template.

Configuring the template
The configuration of a publication template consists in populating the name of the template (i.e. the
identification key consisting of the name and the namespace), the data schema, and the input form.
The Check status to validate content generation option forces a check on the "Validated" status
of the content instances to authorize generation for a file publication.
Transformation templates
A transformation template must be added for each output document.
The Name of template field is a free label that describes the type of rendering at the output.
The publication parameters are entered in the tabs.
Rendering
The Rendering tab gives the rendering type used for the output document. You must populate the
following fields:
Stylesheet: Select the stylesheet and the output format (HTML, Text, XML, RTF),
JavaScript: Select the JavaScript template and the output format (HTML, Text, XML, RTF).
290 | © Neolane 2010

Publication
Publication consists of generating the output document in the form of a file, if the type selected
is File.
The output file encoding character set can be forced via the Encoding field. The Latin 1 (1252)
character set is used by default.
The Multi-file generation option activates a special document publication mode. This option
consists of populating a partitioning tag at the beginning of each page of the output document.
The generation of the content will produce a file for each populated partitioning tag. This mode
is used to generate mini-sites from a content block.
The Location field contains the name of the output file. The name can be made up of variables
in order to generate an automatic filename.
A variable is populated with the following format:
: <path> is the path of a publication template data schema field.
The name of a file can consist of a date-type field. To format this field correctly, use the
function, using the path of the field and the output format as parameters.
Example: building a file name using variables on the "@name" and "@date" fields.
This example generates a filename like this: ct_news12_20090401.htm
Delivery
This tab lets you select a scenario in order to launch a delivery directly on the content. The
content of the e-mail will be populated automatically according to the output format (HTML
or Text).

Aggregator
Aggregation processing of the data from a JavaScript script or query list can enrich the XML document
with the content data. The principle is to supplement certain information referenced by links or to
add elements from the database.
292 | © Neolane 2010

Neolane v5.1 - Configuration Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Neolane v5.1 - Configuration Guide

Caricato da

Copyright:

Formati disponibili

Configuration Guide

Neolane v5.1 - Configuration Guide

Neolane v5.1 - Configuration Guide | 3

Neolane v5.1 - Configuration Guide - Neolane data model | 9

Accessing the data schemas in Neolane

Physical and logical data

Auto-incrementing primary keys

Neolane v5.1 - Configuration Guide - Neolane data model | 11

Neolane v5.1 - Configuration Guide - Neolane data model | 13

NmsGroup and NmsRcpGrpRel

NmsService, NmsSubscriptions and NmsSubHisto

Neolane v5.1 - Configuration Guide - Neolane data model | 15

Neolane v5.1 - Configuration Guide - Neolane data model | 17

NmsTrackingLog and NmsTrackingUrl

Neolane v5.1 - Configuration Guide - Neolane data model | 19

Folder model (sModel) Table of the data Description

Delivery and tracking

Figure 1.1. Simplified diagram of delivery and tracking

Neolane v5.1 - Configuration Guide - Neolane data model | 21

Delivery to mobile channels

Error code Values in nms:broad- NetSize values

Figure 1.2. Simplified diagram of response management

Neolane v5.1 - Configuration Guide - Neolane data model | 23

Neolane v5.1 - Configuration Guide - Neolane data model | 25

Figure 1.3. Simplified offer management diagram

Neolane v5.1 - Configuration Guide - Neolane data model | 27

Figure 1.4. Simplified campaign management diagram

Neolane v5.1 - Configuration Guide - Neolane data model | 29

Neolane v5.1 - Configuration Guide - Neolane data model | 31

Neolane v5.1 - Configuration Guide - Neolane data model | 33

Neolane v5.1 - Configuration Guide - Neolane data model | 35

Neolane v5.1 - Configuration Guide - Extending schemas | 37

Neolane v5.1 - Configuration Guide - Extending schemas | 39

With its corresponding data schema:

Here is our example schema with the types entered:

Neolane v5.1 - Configuration Guide - Extending schemas | 41

Labels and descriptions

The desc property lets you enter a long description.

Example of an enumeration declaration in the data schema:

Neolane v5.1 - Configuration Guide - Extending schemas | 43

With projection of the XML content:

Referencing with XPath

Neolane v5.1 - Configuration Guide - Extending schemas | 45

Building a string via the compute string

Neolane v5.1 - Configuration Guide - Extending schemas | 47

The SQL field constraints are as follows:

Description of data in HTML format:

Calculated field using an SQL expression:

Neolane v5.1 - Configuration Guide - Extending schemas | 49

Multiple choice field:

Indexes obey the following rules:

Keys obey the following rules:

Neolane v5.1 - Configuration Guide - Extending schemas | 51

The schema generated:

Adding a primary or internal key on the "id" name field:

Neolane v5.1 - Configuration Guide - Extending schemas | 53

The schema generated:

Links: relation between tables

Links obey the following rules:

Neolane v5.1 - Configuration Guide - Extending schemas | 55

The extended schema generated:

Neolane v5.1 - Configuration Guide - Extending schemas | 57

The schema generated:

Neolane v5.1 - Configuration Guide - Extending schemas | 59