How to add custom validation logic on mobile phone field in Contact TI
My series of Cloud Application Studio Blogs
- How to detect EditMode in an Embedded Component
- Step by step to enable your custom BO with attachment upload functionality
- Step by step to create an Adobe Print form in Cloud application Studio
- How to render PDF which displays picture from the image attachment of your custom BO
- How to get current logged on business user’s employee information and assigned organization unit via ABSL
- How to implement dynamic access control based on custom BO using OWL
- How to make Code List Restriction work when control field and restricted field are not on the same BO
- How to implement custom number range using custom business object
- Two approaches to create Code List in Cloud Studio
- Create Dynamic Code List via Custom Business Object Association
- Step by step to develop Thing Type based navigation and BO Object based navigation
- Put Extension field into embedded component and make it visible in Standard UI
- One possible cause that embedded component fails to display in UI
- Step by step to create HTML Mashup and make it visible in UI
- Step by step to enable Text Collection for your custom BO
- Automatically send an Email notification to line manager via Workflow in Account application
- Step by step to create Object Value Selector in Cloud Application Studio
- Two approaches to fill an UI field with dedicated logic implemented in Cloud Application Studio
- How to execute BO action on multiple selected BO instances in AdvancedListPane
- How to add custom validation logic on mobile phone field in Contact TI
- An example about how I analyze why some OBN button does not work
- Step by step to create OBN button which navigates from standard UI to custom UI
There is a good blog SAP Cloud for Customer Phone Number Parsing and Formatting which gives a detail explanation about the parse logic of phone number parse logic in C4C. By default it allows the Alphanumeric Value to be entered, the reason of this behavior is explained in note 2525818 – In an Account and Contact, the Phone Number Allows Alphanumeric Value.
However, at least in China, a valid mobile phone number only consists of pure numeric values. The requirement of local customer is whenever the value other than pure number is maintained, the error message will be popped up and the save is terminated.
The fulfilled scenario is: for example if I input an “A” character in Mobile field and press save button, error message is raised:

And save is prevented.

Here below is how to achieve this custom validation logic in Cloud Application Studio.
Create an extension field phoneInvalidRel in BO BusinessPartnerRelationship, and declare the error message to be raised when invalid digit is detected.

Implement BeforeSave event. This event is responsible to check whether the mobile phone number consists of pure numeric value and set the check result into extension field phoneInvalidRel, which will be used by onSave Validation later.
import ABSL;
var phone;
this.phoneInvalidRel = false;
var BPRelationship = this;
if ( !BPRelationship.ContactPerson.IsSet())
return;
var contact = BPRelationship.ContactPerson;
if( !contact.ContactPersonWorkplaceAddressInformation.IsSet())
return;
var workplaceAddress = contact.ContactPersonWorkplaceAddressInformation;
if( !workplaceAddress.ContactPersonWorkplaceAddress.DefaultMobilePhone.IsSet())
return;
phone = workplaceAddress.ContactPersonWorkplaceAddress.DefaultMobilePhone;
if( phone.FormattedNumberDescription.IsInitial())
return;
if( phone.FormattedNumberDescription.FindRegex("1\\d{10}") < 0){
// raise "Invalid mobile phone number!";
this.phoneInvalidRel = true;
raise Error_phone_msg_rel.Create("E", phone.FormattedNumberDescription );
}
Implement OnSave validation, and simply use the check result stored in extension field phoneInvalidRel.
import ABSL;
return !this.phoneInvalidRel;
In the runtime, when I enter “A” in mobile phone field and save, first the BeforeSave event is triggered,

And then the onSave Validation is called.

The above implementation could only cover the scenario that end user directly changes the mobile phone number which is technically modelled in BO BusinessPartnerRelationship. There is another possibility that end user will also changes the field on Root node of BO BusinessPartner, as a result the same logic should be done again on BO BusinessPartner as well.

BeforeSave implementation on BusinessPartner Root node:
import ABSL;
var phone;
var common = this.Common.GetFirst();
common.phoneInvalid = false;
if( !this.CurrentDefaultIsContactPersonFor.IsSet())
return;
var currentDefaultContact = this.CurrentDefaultIsContactPersonFor;
var BPRelationship = currentDefaultContact.BusinessPartnerRelationship;
if ( !BPRelationship.ContactPerson.IsSet())
return;
var contact = BPRelationship.ContactPerson;
if( !contact.ContactPersonWorkplaceAddressInformation.IsSet())
return;
var workplaceAddress = contact.ContactPersonWorkplaceAddressInformation;
if( !workplaceAddress.ContactPersonWorkplaceAddress.DefaultMobilePhone.IsSet())
return;
phone = workplaceAddress.ContactPersonWorkplaceAddress.DefaultMobilePhone;
if( phone.FormattedNumberDescription.IsInitial())
return;
if( phone.FormattedNumberDescription.FindRegex("1\\d{10}") < 0){
// raise "Invalid mobile phone number!";
common.phoneInvalid = true;
raise Error_phone_msg.Create("E", phone.FormattedNumberDescription );
}
OnSave Validation on BusinessPartner Root node:
import ABSL;
var common = this.Common.GetFirst();
return !common.phoneInvalid;
Be the first to leave a comment
You must be Logged on to comment or reply to a post.