Name: Using Markup Extensions in SAP Customer Data Cloud
Uploaded: 2023-3-2
Duration: 397 s
Description: In this demo video, we’ll show you how to use markup extensions to build a simple screen-set from scratch and use it in the application.You can view the documentation on the SAP Help Portal for more details:Markup Extensions | SAP Help Portal

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div><p>In this demo video, we’ll show you how to use markup extensions to build a simple screen-set from scratch and use it in the application.</p><p>You can view the documentation on the SAP Help Portal for more details:<br><a href="https://help.sap.com/docs/SAP_CUSTOMER_DATA_CLOUD/8b8d6fffe113457094a17701f63e3d6a/41650d4770b21014bbc5a10ce4041860.html?q=markup%20extensions" rel="nofollow noopener noreferrer" target="_blank">Markup Extensions | SAP Help Portal</a><br></p></div></div></div></div></div>

Using Markup Extensions in SAP Customer Data Cloud

In this demo video, we'll show you how to use markup extensions to build a simple screen set from scratch and use it in the application. A good first step is to establish the outline of the screen set and the screens that it will contain. Let's introduce a few divs into our markup. Divs with a class of gauges screen set are interpreted by the. Get JavaScript as the parent div screen. Screen set divs have IDs which are used as a screen set ID when making a method. Call to account dot show screen set. We set the CSS display value of the screen set to none, which prevents the entire screen set from being displayed at once. The get JavaScript will understand what HTML elements to make visible when the appropriate call to account start show screen set is made. Divs with a class of a gauges screen will contain the form and their respective controls and widgets for any step of the user flow that the screen set is meant to handle. The ID attribute of these divs can be used as the start screen property when calling accounts. Dot show screen set range. Because the user flow can branch off into one of several directions. We can use one of the markup extension data attributes to define what screen should be used in certain circumstances. For better readability, we'll move the screen set divs attributes to separate lines. You'll find that most markup extensions are entirely optional. However, for the screen set itself, a height and width attribute must be defined. These are used when there's no container ID given. When account start, show screen set is called in order to define the dimensions of the screen set dialog. Next, we add the actual form elements to the screen. Set. Markup extensions reserved several classes specifically for form elements which define to get JavaScript what type of form this is meant to be, and how to manage its behavior. In this screen set, we're using the Google login registration profile, reset password link account and resend verification in form. There's no registration completion form because that registration completion screen simply sets account data. So get get profile form classes are used. Once the user has successfully submitted the form on a screen. The screen set will either have to continue on to the next screen or finish. This is accomplished by using the data attribute on success screen. Either set it to the ID of the next screen or the keyword underscore finish, which tells the screen set logic that the user has completed all of the expected steps of their flow. There's also a special auto skip data attribute that is reserved for profile forms. This tells the screen set logic that if on this form, all the fields that are marked as required in the schema have data, then the screen set should continue to the on success screen defined for this form debris. The next step is to add the actual form elements for a user to input data and interact with the form. Get JavaScript will determine the mapping of input elements to the account data by inspecting the name attributes of those elements. There are three types of input names that are acceptable. Name attributes that start with profile dot will map to this core profile data. Custom data field names can be mapped to using the data dot field name convention, and the last type of input name or set of reserved names is for special fields such as login ID, password and password. Retype the data e.g. a placeholder attribute provides the same functionality that the standard placeholder attribute provides, but extends that functionality to browsers that don't support the placeholder attribute natively. Screen set forms must be submitted in order to work for this. The standard submit functionality of forms will work. Using markup extensions, we can add some widgets that will provide additional functionality for the user during the login and registration process. Here we add a social login and a Captcha widget. SAP Customer Data SAP Customer Data Cloud uses two classes for displaying errors. You get error MSG, which will display a predefined text error message and get error display, which is for showing elements when there is an error. For elements with either of these classes, there's a data bound to attribute that connects to state of the error element with either a form element for specific errors, or the form itself for errors that would result from submitting the form, with all the fields meeting expected criteria but still failing to allow the user to navigate to different screens. Markup extensions provide a data switch screen attribute for anchor tags, the value of which would be the screen the user would be allowed to navigate to. The most common use case for this attribute is to allow the user to switch between the login and registration screen. We now have an Unstyled but working login and registration form. Let's see it in action. For this example, we've copied the markup of the screen sets into the console using the advanced Customization link underneath the screen. Set option. First, we should confirm that the screen sets show up. We've tied event listeners to the login and registration links in the header to call accounts. Dot show screen set. Passing in our screen set ID and desired start screen as parameters. The screen sets show up as expected and at first glance have all the fields based on the markup that was created. We'll confirm that the anchor tags work. We'll also check that the error messaging works. It does note that the first name and last name aren't required fields for registration, which is why they aren't in any error state. We'll confirm that the screen sets work by first registering an account, logging out, and then logging back in. As you can see, using markup extensions is more involved than building user workflows in the UI builder. However, it provides direct access to the screen set HTML, which can be used to allow deeper customization of the UI. Thank you for watching.