...
Sample Configuration:
Code Block | ||
---|---|---|
| ||
"DataValidationConfiguration": { "IdentifierFields": [ "OrgLoginId" ], "CriticalFields": [ "Rank", "Vessel", "FirstName", "LastName" ], "RegularFields": [ "ContactEmail" ], "PasswordFields": [ "DateOfBirth" ], "FieldFormattings": [ { "FieldName": "LastName", { "Name": "OrgLoginId", "Type": "String" } ], "CriticalFields": [ { "Name": "Vessel", "Type": "String" }, { "FieldName }, { "Name": "VesselFirstName", "Type": "String" }, { "FieldName }, { "Name": "RankLastName", "Type": "String" }, { "FieldName }, { "Name": "OrgLoginIdRank", "Type": "String" }, { "FieldName": "FirstName", "Type } ], "RegularFields": [ { "Name": "StringEmailAddress", "Format "Type": "Xn*EmailAddress" }, { "FieldName { "Name": "DateOfBirthDeptCode", "Type": "DateTime", "Format": "dd-MM-yyyy" }, { "FieldName": "ContactEmail", String" } ], "PasswordFields": [ { "Name": "Password", "Type": "EmailAddress" } ] String" } ] } |
This activity validates all parsed user objects according to configuration and LMS specification (i.e. single choice field must have the proper value).
...
IdentifierFields used to uniquely identify a user (i.e. OrgLoginId, login email address). Currently it supports one identifier field.
Critical field which needs data validation and would stop processing the whole user if it contained invalid data (skip user). Continue with any other users though.
Regular fields would not stop a user from being processed. If a regular field contained invalid data, the field would not be updated/set. The remaining user fields would be updated if their data was OK. Any not processed regular field should be reported on.
Password fields used for password creation only.
Every field added in any of these field types must present in field formatting sectionsmust have a Name and Type.
Password Configuration
Sample Configuration:
...