by Contributed | Mar 19, 2021 | Technology
This article is contributed. See the original author and article here.
The use of virtual hostnames with SAP systems is a familiar approach to SAP customers, allowing the decoupling of actual SAP Server hostnames from the hostname referred to by the SAP instance. It provides a degree of abstraction allowing for simpler virtualization, naming conventions, hardware lifecycles, organizational policies, datacenter migrations and Disaster Recovery.
This blog post will provide step-by-step instructions on how to reliably deploy an Azure VM with the actual VM Server hostname, as well as the SAP Virtual hostname on a single network interface. These instructions only apply to Windows Operating system.
NOTE: Please note that the configuration described in this article does not apply to servers using Windows Server Failover Clustering (WSFC) which can provide high availability to SAP Database and SAP Central Services servers(A/SCS.) This configuration can be applied to SAP Application Servers and 2-tier SAP systems (Application, and SCS servers installed on a single VM.)
More detail
When migrating to Microsoft Azure, many customers choose to use a single network interface for their SAP VMs, as it simplifies automation of deployments and management. A common design misconception is that multiple network interfaces increase network throughput, however in Microsoft Azure, unlike many on-premises configurations, Azure Virtual Machines can scale network bandwidth to their potential maximum for that VM size with just a single network interface. There is no need for multiple network interfaces to scale bandwidth.
As detailed in SAP Note 2109662 – Windows returns wrong IP address as source IP however, the SAP installation will throw an error unless Windows IP addresses and the DNS registration of VM hostname and the SAP Virtual hostname are configured properly.
This configuration is detailed in SAP Note 1564275 – Install SAP Systems Using Virtual Host Names on Windows, however this blog will focus on how to accomplish this specifically in Microsoft Azure.
Technical Solution
In this blog we will use the example of an SAP App server with 1 Network Interface attached and the following configuration:
- Subnet:
- Name = App
- CIDR = 10.0.0.0/26
- Netmask = 255.255.255.192
- Default Gateway (1st IP address of subnet) = 10.0.0.1
- IP address/FQDN:
- 10.0.0.8 = sapapp.contoso.local (<- VM fully qualified domain name)
- 10.0.0.9 = sapvhost.contoso.local (<- SAP virtual fully qualified domain name)
Figure 0: A layout of what we want to achieve
First, let us look at the updates needed from the Portal.
When you are adding an additional IP configuration to the Azure NIC from Microsoft Azure portal, you can add an additional IP configuration on the Home > Network interface > “NIC Name” > IP configurations blade in the following way:
Figure 1: Open NIC configuration blade and click “Add”
Figure 2: adding second IP configuration in the add ipconfig blade
Now we move to the VM and RDP into it. The first thing you will notice once you boot-up is that, only one IP configuration is visible in the VM. The reason is that Azure DHCP, by default, assigns the primary IP configuration from the Azure NIC to the network interface within the VM. The secondary IP configurations must be manually assigned at the VM OS level.
Figure 3: Output of “ipconfig /all” on the VM
Now that we are on the VM, let us walk through the steps needed to allow us to use SAP virtual hostnames on Windows.
- Windows Servers provide a convenient capability to register each of its assigned IP addresses in DNS. This means that some of the default options allow Windows Server machines to automatically register the IP addresses of the network adapters in DNS after a server restart. To prevent this, you must unset the “Register this connection’s addresses in DNS” option for the network adapters. This setting can be found on the DNS tab of the Advanced TCP/IP Settings property window for TCP/IPv4. This is a very important step, if we do not unset the option the Windows DNS client service registers both IP addresses for the Windows host name in DNS resulting in name resolution issues.
Figure 4: Uncheck the checkbox highlighted to prevent auto registration of IP addresses.
- Make sure that the Remote registry service is enabled and running. This would be required to make changes in the registry to update the properties of the network adapters registered with DNS.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersDNSRegisteredAdapters{<36 character GUID corresponding to the network adapter that TCPIP was bound to>}
- Now we add the additional IP configuration on the network card
- On the “General” tab of the TCP/IPv4 properties, change the IP address acquisition to manual. This is because, as explained above, Azure DHCP only propagates the primary IP configuration to the network adapter, and we want both the IP addresses assigned to it.
Figure 5: Set the IP addresses manually
Note: If you set this properly, you will experience a short disconnection to your RDP session and connect back. If you did not set any of the properties correctly, you will not be able to connect back until the VM is rebooted.
- In the “IP Settings” tab of the advanced settings property window, you should see the manually entered IP address.
Figure 6: the primary address should show up on the “Advanced” properties window
- Add the additional IP address by clicking “Add”. The “IP settings” tab should look like below before clicking OK.
Figure 7: After adding the secondary IP configuration on the network adapter
- Next, we set “SkipAsSource” to “True” (default is “False”) for the secondary IP Address i.e., 10.0.0.9, which we added in the above step. We do this to prevent the secondary IP address from registering in DNS automatically. If “SkipAsSource” is set to “True”, then that IP address will not be registered in DNS and will not be used for host initiated outgoing communications, unless an application specifically binds to it. The preferred way to do this is via PowerShell (as shown below).
#Get interface alias, ip addresses and the skip as source before starting
Get-NetAdapter | Get-NetIPAddress | `
Where-Object -FilterScript { $_.AddressFamily -eq "IPv4" } | `
Select-Object InterfaceAlias, IPAddress, SkipAsSource
$primaryIP = "10.0.0.8" #replace with your primary ip
$netInterface = "Ethernet 3" #replace with your network adapter name
# get all the IP addresses on the interface, filtered by IPv4 and excluding
# the $primaryIP
[array]$IPs = Get-NetIPAddress -InterfaceAlias $netInterface | ``
Where-Object { $_.AddressFamily -eq "IPv4" -and $_.IPAddress -ne $primaryIP }
# set primary IP SkipAsSource to false
Set-NetIPAddress -IPAddress $primaryIP -InterfaceAlias $netInterface -SkipAsSource $false
# set other IP addresses with SkipAsSource equal to true
Set-NetIPAddress -IPAddress $IPs.IPAddress -InterfaceAlias $netInterface -SkipAsSource $true
#check all properties are set properly
Get-NetAdapter | Get-NetIPAddress | `
Where-Object -FilterScript { $_.AddressFamily -eq "IPv4" } | `
Select-Object InterfaceAlias, IPAddress, SkipAsSource
Once we complete running the code, the output from the Get-NetAdapter command above should look like this:
Figure 8: setting “SkipAsSource” to True on the secondary IP address of the NIC
- At this point we can create the Host (A) records in DNS for the Virtual Hostnames. For the reverse lookups to work, we need to ensure the flag; “Update associated pointer (PTR) record”, is set on both the addresses.
Figure 9: Host (A) records in DNS for the server and virtual hostnames
Figure 10: setting to update the PTR records in DNS
- On the VM, we need to notify Windows that the Virtual Hostname being used is actually an alternate name for the computer. We do this by adding a new multi-string value ‘BackConnectionHostnames’ under the “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0” key. You can use the below PowerShell for doing this, change the sapvhost and sapvhost.contoso.local to the virtual hostnames’ short-name and FQDN.
New-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlLsaMSV1_0' `
-Name "BackConnectionHostNames" `
-Value "sapvhost","sapvhost.contoso.local" `
-PropertyType MultiString
Note: This setting would not need a server restart to work. You can complete all the steps and reboot the machine
- Now that we have notified Windows that the machine has alternate names, we need to also tell Windows to allow inbound connections which are directed to this Virtual Hostname. We do this by adding a DWord value called ‘DisableStrictNameChecking’ under the key “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparameters”
New-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetServiceslanmanserverparameters' `
-Name "DisableStrictNameChecking" `
-Value "1" `
-PropertyType DWord
- At this point, we can reboot the VM.
- Once the VM is back online, we can log back in and do some validations
- Let us check if the ipconfig shows both the IP Addresses. We can do this after adding the second IP on the NIC as well.
Figure 11: validating that the second IP shows up in ‘ipconfig /all’ command
- Validate that reverse lookup works for the secondary IP
Figure 12: validating that reverse lookup works for secondary IP
- Check that the DisableStrictNameChecking and BackConnectionHostnames settings are working by running “net view virtualhostname” and browsing to the virtual hostname through the command prompt. Ideally, run these from a different machine to check further.
Figure 13: checking the shares are available by running net view command
- Another good test is to open the Computer Management MMC and open the virtual hostname from Action -> Connect to Another Computer -> virtual host name. If you can browse the ‘Local Users and Groups’ and ‘Services and Applications’, it is a good sign and SAPinst should be successful.
Figure 14: Test connecting to SAP virtual hostname from MMC
- Once all the tests from above tests have succeeded, we can start with the SAP installation using the virtual hostname now by running SAPinst from an administrative command prompt and execute the following command: SAPinst.exe SAPINST_USE_HOSTNAME=<virtualname>.
Summary
To recap the configuration above, here are the 6 basic steps required on the Windows virtual machine to prep it for SAP installation using virtual hostnames with a single network interface:
- Uncheck the “Register this connection’s addresses in DNS” setting on the primary NIC
- Add a second IP address configuration through the Azure Portal, and then within the VM add the second IP address to the Network Interface’s IPv4 properties
- Follow SAP Note 2109662 – using PowerShell set the “SkipAsSource” property on the second IP address (desired outcome: first IP address à SkipAsSource=false; secondary/virtual IP address à SkipAsSource=true)
Figure 15: After setting SkipAsSource, the interface details
- 10.0.0.8 = actual VM hostname, will automatically register in DNS
- 10.0.0.9 = virtual SAP hostname, will not automatically register in DNS, we will manually create this DNS record
- Maintain the registry entries:
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparametersDisableStrictNameChecking = 1 (Type: DWORD)
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0BackConnectionHostnames = FQDN short hostname (Type: Multi-string value)
(ex: sapvhost.contoso.local sapvhost <Not a space, but a carriage return between these>)
- Re-set the “Register this connection’s addresses in DNS” setting on the primary NIC
- Outcome:
- VM Primary IP Address (10.0.0.8) will register in DNS with actual VM hostname
- You must manually create an A-record for the VM secondary IP Address 10.0.0.9 and the virtual SAP Hostname
To ensure you have completed these steps correctly you can validate the configuration by:
- DNS forward lookup (e.g., “nslookup sapvhost.contoso.local”)
- DNS reverse lookup (e.g., “nslookup 10.0.0.9”)
- Browse to the sapvhost.contoso.local UNC address through either the command prompt or File Explorer.
After executing this set of steps on your VM, you are now prepared to start the SAP installation by starting SAPinst on the VM using virtual hostnames. Start SAPinst from an administrative command prompt and execute the following case-sensitive command: SAPinst.exe SAPINST_USE_HOSTNAME=<virtualhostname>.
References
by Contributed | Mar 19, 2021 | Technology
This article is contributed. See the original author and article here.
Introduction
In a previous blog post, the basic building blocks of custom column formatting were introduced to us. From that, we learned how to customize our columns to create some interesting visuals.
Things look better, but each column is still a separate component. What if we want to tie them all together into a more cohesive presentation?
The good news is that we can! Just like we customized our columns, we can also customize SharePoint list views! That will allow us to go from a traditional table/column/cell view, to something that looks ‘put together’, like so…
Preparing for your journey
Before you get going, there are a few things that will help prepare you for the trek ahead.
If you haven’t, I would highly recommend reading the first blog post in this series: Getting started with SharePoint’s custom column formatting.
You can also refer to the official documentation for view formatting to help fill in any gaps not covered here.
I should also warn you that your HTML and CSS skills are going to come into play a lot more here, as you’ll be trying to work with multiple elements to position them correctly.
If you’re not an expert, that’s perfectly okay – I’m not one either – you’ll just need an extra dose of patience. Trial and error will get you there, eventually. I’m not going to dwell on the particular CSS used in these examples except in cases where it’s a pattern that could be applied to other use cases.
And that’s pretty much it. There’s some new stuff we’ll learn about that only applies to View formatting, but everything we learned from the previous blog post will apply here as well.
Choose your own adventure
In case you weren’t aware, views in a Modern SharePoint list come in a few flavors.
Most of us are probably already very familiar with the List layout; It’s what we’ve been used to for decades. Compact List is the same as List…just smaller. The Tiles view, frequently referred to as the Gallery view, is somewhat newer. As you may expect, it will display your list items as cards/tiles in a classic grid view. There’s also a Calendar view/layout that was recently added, but is not currently customizable.
When it comes to custom formatting, we can customize both the List and Gallery layouts. They do need to be customized separately, as their schemas are slightly different, but they’re close enough that you can usually take your JSON from one and apply it to the other with minimal changes.
For our journey here, we’re going to start with a List view and then use it to create a Tile view.
I wisely started with a map
Before we get into defining our custom view formatting, it may be helpful to spend some time up front thinking about how we’ll structure our view. The more you want to transform your view, the more important it will be to plan things out in advance. This is where some understanding of HTML will come in handy.
To help guide myself, I created the following image to try and visualize how my various DIVs and other elements would be laid out.
This isn’t necessary, obviously, but I personally find it helpful to have a blueprint in front of me (even if it’s only a mental one).
Formatting List views
If you recall from the column formatting article, each custom format followed the same basic structure: A $schema definition along with a parent HTML element and optional attributes, styles and children.
{
“$schema”: “https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json”,
“elmType”: “div”,
“attributes”: {
“iconName”: “Game”
},
“style”: {
“font-size”: “48px”,
“color”: “red”
},
“children: []
}
List views aren’t that much different.
{
“$schema”: “https://developer.microsoft.com/json-schemas/sp/v2/row-formatting.schema.json”,
“hideSelection”: true,
“hideColumnHeader”: true,
“rowFormatter”: {}
}
We still have our $schema property, but it’s important to notice that it’s pointing to a different schema definition. We also have some new optional properties: hideSelection & hideColumnHeader. As you may suspect, hideSelection will do away with the ability to select a particular list item while hideColumnHeader will do away with the the column headers normally present on a list.
What’s a little different here is that we’re missing our parent element. Instead, we have this rowFormatter property. The reason for this is that we can choose between using this and an additionalRowClass property. If you choose the latter, you’re limited to applying CSS classes to the entire row, similar to what you can do with the out-of-box “Conditional formatting”. If all you want to do is make your row a different color, you’re probably better off using the design mode tools, but if you’re interested in learning more about the additionalRowClass property, it is covered well enough in the official documentation.
We, however, will not be satifisfied with applying some simplistic styling. NO! We are bound for greater rowFormatter glory!
NOTE: There are other properties available that are not covered in this blog, most notably the groupProps property. This allows you to customize the grouping header that appears when items are grouped together by some column. There are also footerFormatter and hideFooter properties that affect the “List Footer” that appears if you’re displaying item totals.
One container to rule them all
The rowFormatter property is simply an object that wraps all of the HTML elements we’re going to create our view. If, for some reason, we wanted every row in our list to just simply display the basic column formatting shown in the previous section, we’d end up with the following JSON definition.
{
“$schema”: “https://developer.microsoft.com/json-schemas/sp/v2/row-formatting.schema.json”,
“hideSelection”: true,
“hideColumnHeader”: true,
“rowFormatter”: {
“elmType”: “div”,
“attributes”: {
“iconName”: “Game”
},
“style”: {
“font-size”: “48px”,
“color”: “red”
},
“children: []
}
}
That’s probably not the greatest idea, but it does illustrate the point. Once we make it inside of the rowFormatter object, it’s almost business as usual. There’s one more difference we need to understand…how we reference columns.
How to reference fields
When we were dealing with formatting individual columns, we always used the built-in variable @currentField, but what about when we’re dealing with more than one view? @currentField is still there, but it holds a slightly different meaning in this context. It will always be a reference to the standard Title field.
Instead of using @currentField to reference a column, we’ll need to use a slightly different format: [$InternalColumnName].
In our list, we have a handful of columns including a Member lookup column. If we want to reference that field, we’d use [$Member]. Even if we change the display name from “Member” to “Hero”, our variable would still be [$Member]. And, since Member is a lookup column, if we want to show the display name of the user, we need to use the title property. We’d do that in the following way [$Member.title].
The World Is Not In Your Books And Maps. It Is Out There.
Alright. Enough with the lessons, it’s time to get started.
We can use the “map” we created earlier and turn it into a rough skeleton. Each layer in that blowout represent a parent/child relationship. So, by looking at our map…
We come up with this.
{
“$schema”: “https://developer.microsoft.com/json-schemas/sp/v2/row-formatting.schema.json”,
“hideColumnHeader”: true,
“hideSelection”: true,
“rowFormatter”: {
“elmType”: “div”,
“attributes”: { “title”: “Parent Container” },
“children”: [{
“elmType”: “img”,
“attributes”: { “title”: “Background Image” },
“children”: [{
“elmType”: “div”,
“attributes”: { “title”: “Column Container” },
“children”: [
{
“elmType”: “div”,
“attributes”: { “title”: “Member/Role DIV” },
“children”: [
{
“elmType”: “img”,
“attributes”: { “title”: “Large Member profile picture” }
},
{
“columnFormatterReference”: “[$Title]”
}
]
},
{
“elmType”: “div”,
“attributes”: { “title”: “Text DIV” },
“children”: [{
“elmType”: “div”,
“attributes”: { “title”: “Member Name row/div” }
},
{
“elmType”: “div”,
“attributes”: { “title”: “Age row/div” }
},
{
“elmType”: “div”,
“attributes”: { “title”: “From row/div” }
}
]
},
{
“elmType”: “div”,
“attributes”: {
“title”: “Race/Weapons DIV/Column”
},
“children”: [{
“elmType”: “div”,
“attributes”: { “title”: “Race icon DIV/Row” },
“children”: []
},
{
“elmType”: “div”,
“attributes”: { “title”: “Weapon icons DIV/Row” },
“children”: []
}
]
}
]
}]
}]
}
}
That’s the basic layout of our custom view, simply a series of parent and child divs. We’ll start filling this skeleton out with content shortly, but there are a couple of things to point out already.
First, there are several examples of this “attributes”: { “title”: “<TEXT>” } pattern. We can use this as a means of commenting about the purpose of the element, since comments aren’t allowed in valid JSON and would break our view. Again, this isn’t required and adds absolutely no value to the view itself. It does, however, help keep us (and any future adventurer) oriented as to where we are in our JSON.
NOTE: Using the title attribute will cause whatever you specify to be displayed as a tooltip when a user hovers over the element. You can remove your titles after you done, if that bothers you. Otherwise, just be aware that users may see your witty comments.
Also, in the “Member/Role DIV” children, the second child looks a little peculiar.
{
“columnFormatterReference”: “[$Title]”
}
This columnFormatterReference property is a nifty shortcut that tells the view formatter to display the referenced field (Title, in this case) as it normally would, including any custom column formatting that may have been configured. This is a great opportunity for some reusability, especially if you want the column to show exactly the same way on every view.
If you take our skeleton and put it into SharePoint, there’s not going to be much to look at. So let’s fix that.
Putting some meat on the bone
Now that we’ve got our skeleton all rigged up, it’s time to fill it out some.
It’s certainly a little short and skinny, so let’s start by defining some CSS on our parent div. We know we want a border around the whole thing, as well as a particular font style and size, so we can apply those things at the top level.
“style”: {
“position”: “relative”,
“border”: “5px solid black”,
“border-radius”: “10px”,
“width”: “600px”,
“height”: “175px”,
“font-family”: “Luminari, Papyrus, Brush Script MT”,
“font-size”: “24px”
}
We’re also specifying a position value of “relative”, which tells the browser to display that DIV relative to it’s parent container. In this case, that parent container will be the row in the list. It won’t have any noticeable effect here, but will help us later.
Let’s also go ahead and setup our second layer too, our background image. Normally, we’d just use the css property background-image and point it to a URL. Unfortunately, we can’t do that here because the ( character is prohibited in most use cases. So, instead, we have to use an img element and size it appropriately.
{
“elmType”: “img”,
“style”: {
“width”: “100%”,
“height”: “100%”,
“z-index”: “-3”,
“opacity”: “.5”
},
“attributes”: {
“title”: “Background Image”,
“src”: “=@currentWeb + ‘/SiteAssets/MiddleEarthLocales/’ + [$From.lookupValue] + ‘.jpg'”
},
“children”: […]
}
We’ve added the src attribute, which should look mostly familiar. Notice, though, that we’re referencing the [$From] variable.
We’re also setting the width and height to be 100% of the parent so the image fills the space and we’re setting the opacity to half so that the image is a little on the transparent side (this will help the text and images we lay on top of it stand out more).
Finally, we’re setting this z-index property to a negative value. Typically, HTML will render any content inside of the div on top of the div. Think of it like a stack of plates. That last thing you put on the stack is the most visible. We can use the z-index property to affect that, and by setting to a negative value here, we’re ensuring that out content will be rendered behind our parent div. Without this, the background image would cover up our border.
Stylin’ and Profilin’
Now that we’ve got our first two layers done, let’s take a look at our third layer. If we refer back to our skeleton, we can see that our img element has a single child titled “Column Container”, and that child has three children of its own. What we want to happen is to have a three-column layout and to do that, we’re going to style this “column container” like so.
“style”: {
“position”: “absolute”,
“width”: “100%”,
“height”: “100%”,
“display”: “flex”
}
We have to specify the width and height here as being “100%” because, without it, the DIV will only grow as large as the content and we want to ensure that it stays as large as it can. We’re also specifying a different position value here – absolute – which basically tells the browser to render our DIV at a specific position. In this case, we’re letting it default the starting point, which is the “top left corner” of the first ancestor element with a “position” attribute on it (in this case, our parent div, which we said was relative positioned).
We’re also specifying a display property with a value of flex. This creates what’s known as “Flexbox” which will help us deal with the concept of turning our child DIVs into “Columns” and “Rows”.
Now that we’ve got our container, let’s work on the next three children, which will represent our three columns.
First column
We’ll just div right into the definition for our first column, which is a simple parent div to hold our image and role icon.
{
“elmType”: “div”,
“attributes”: { “title”: “Member/Role DIV” },
“children”: [
{
“elmType”: “img”,
“attributes”: {
“src”: “=replace([$Member.picture], ‘MThumb’, ‘LThumb’)”
},
“style”: {
“height”: “175px”,
“width”: “175px”,
“border-style”: “solid”,
“border-color”: “black”,
“border-width”: “0px 5px 0px 0px”
}
},
{
“columnFormatterReference”: “[$Title]”
}
]
}
Two points of interest here.
First, for the src attribute for our img property, we’re using the replace() function to swap out the text ‘MTHUMB’ for ‘LTHUMB’. When a user uploads a profile picture, SharePoint will create three versions of it (large, medium, and small). For formatting, referencing the picture property will always return the medium thumbnail. Rather than stretching a smaller thumbnail, we can use pattern to retrieve the larger one instead.
Also, because we formatted the Role (which is a rename of the Title column), we don’t have specify the definition here. Instead, we’re using the columnFormatterReference property and referencing our field.
NOTE: The column formatting for Role was slightly updated from the previous blog.
Just for reference, here’s the definition we created for the custom column formatting used on the Role field.
{
“$schema”: “https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json”,
“elmType”: “div”,
“style”: {
“width”: “24px”,
“height”: “24px”,
“font-size”: “24px”,
“background-color”: “green”,
“color”: “white”,
“position”: “absolute”,
“left”: “0”,
“bottom”: “0”,
“border-radius”: “4px”
},
“children”: [{
“elmType”: “div”,
“style”: {
“margin”: “auto”
},
“attributes”: {
“iconName”: “=if(@currentField == ‘Ring-bearer’, ‘StatusCircleRing’, if(@currentField == ‘Guardian’, ‘Shield’, if(@currentField == ‘Melee’, ‘DecisionSolid’, ‘Bullseye’)))”
}
}]
}
At this point, we have something like the below image.
Second column
Our second column consists of three rows, each containing a different bit of text relating information about the current member. Here’s the definition for this section.
{
“elmType”: “div”,
“attributes”: {
“title”: “Text DIV”
},
“style”: {
“padding-left”: “5px”,
“color”: “white”,
“width”: “inherit”,
“text-shadow”: “2px 2px 0 #000000”,
“font-weight”: “bolder”,
“display”: “flex”,
“flex-direction”: “column”,
“justify-content”: “space-between”
},
“children”: [
{
“elmType”: “div”,
“style”: {
“font-size”: “1.5em”
},
“txtContent”: “[$Member.title]”
},
{
“elmType”: “div”,
“style”: {
“font-size”: “1.25em”
},
“txtContent”: “=’Age: ‘ + [$Age.displayValue]”
},
{
“elmType”: “div”,
“style”: {
“font-size”: “1.25em”
},
“txtContent”: “=’From: ‘ + [$From.lookupValue]”
}
]
}
The only thing of real note here is that our parent container in this case is again defining a “Flexbox” with its display property. We’re also using two new properties, flex-direction and justify-content, to control how our children are displayed relative to one another.
We’re using the width property with a value of inherit to force our column to take up the maximum amount of width possible. It won’t have a noticeable affect here, but will come into play in the next section.
The flex-direction property tells the browser to make each child grow to take up the entire column, width wise. That will force each child div onto its own line.
The justify-content property, on the other hand, tells the browser to evenly distribute our rows across the available height.
We’re getting closer to our desired end result.
The final column
Our last column consists of two rows of equal size to hold our Race and Weapon Icons. Let’s take a look.
{
“elmType”: “div”,
“attributes”: { “title”: “Race/Weapons DIV/Column” },
“style”: {
“width”: “48px”,
“padding”: “5px 5px 5px 0px”,
“display”: “flex”,
“flex-direction”: “column”
},
“children”: [
{
“elmType”: “div”,
“attributes”: { “title”: “Race icon DIV/Row” },
“style”: {
“flex-grow”: “1”
},
“children”: [{
“columnFormatterReference”: “[$Race]”
}]
},
{
“elmType”: “div”,
“attributes”: { “title”: “Weapon icons DIV/Row” },
“children”: [{
“columnFormatterReference”: “[$Weapons]”
}]
}
]
}
There’s nothing new to discuss here, but it does finish off our sample.
The Complete Schema
{
“$schema”: “https://developer.microsoft.com/json-schemas/sp/v2/row-formatting.schema.json”,
“hideColumnHeader”: true,
“hideSelection”: true,
“rowFormatter”: {
“elmType”: “div”,
“style”: {
“position”: “relative”,
“border”: “5px solid black”,
“border-radius”: “10px”,
“width”: “600px”,
“height”: “175px”,
“font-family”: “Luminari, Papyrus, Brush Script MT”,
“font-size”: “24px”
},
“attributes”: {
“title”: “Parent Container”
},
“children”: [{
“elmType”: “img”,
“style”: {
“width”: “100%”,
“height”: “100%”,
“z-index”: “-3”,
“opacity”: “.5”
},
“attributes”: {
“title”: “Background Image”,
“src”: “=@currentWeb + ‘/SiteAssets/MiddleEarthLocales/’ + [$From.lookupValue] + ‘.jpg'”
},
“children”: [{
“elmType”: “div”,
“attributes”: { “title”: “Column Container” },
“style”: {
“position”: “absolute”,
“width”: “100%”,
“height”: “100%”,
“display”: “flex”
},
“children”: [{
“elmType”: “div”,
“attributes”: {
“title”: “Member/Role DIV”
},
“children”: [{
“elmType”: “img”,
“attributes”: {
“src”: “=replace([$Member.picture], ‘MThumb’, ‘LThumb’)”
},
“style”: {
“height”: “175px”,
“width”: “175px”,
“border-style”: “solid”,
“border-color”: “black”,
“border-width”: “0px 5px 0px 0px”
}
},
{
“columnFormatterReference”: “[$Title]”
}
]
},
{
“elmType”: “div”,
“attributes”: {
“title”: “Text DIV”
},
“style”: {
“padding-left”: “5px”,
“color”: “white”,
“width”: “inherit”,
“text-shadow”: “2px 2px 0 #000000”,
“font-weight”: “bolder”,
“display”: “flex”,
“flex-direction”: “column”,
“justify-content”: “space-between”
},
“children”: [{
“elmType”: “div”,
“style”: {
“font-size”: “1.5em”
},
“txtContent”: “[$Member.title]”
},
{
“elmType”: “div”,
“style”: {
“font-size”: “1.25em”
},
“txtContent”: “=’Age: ‘ + [$Age.displayValue]”
},
{
“elmType”: “div”,
“style”: {
“font-size”: “1.25em”
},
“txtContent”: “=’From: ‘ + [$From.lookupValue]”
}
]
},
{
“elmType”: “div”,
“attributes”: { “title”: “Race/Weapons DIV/Column” },
“style”: {
“width”: “48px”,
“padding”: “5px 5px 5px 0px”,
“display”: “flex”,
“flex-direction”: “column”
},
“children”: [{
“elmType”: “div”,
“attributes”: { “title”: “Race icon DIV/Row” },
“style”: {
“flex-grow”: “1”
},
“children”: [{
“columnFormatterReference”: “[$Race]”
}]
},
{
“elmType”: “div”,
“attributes”: { “title”: “Weapon icons DIV/Row” },
“children”: [{
“columnFormatterReference”: “[$Weapons]”
}]
}
]
}
]
}]
}]
}
}
Our adventure draws near its end
Now that we’ve got our view formatted, we’re done, right? We could be, but the list view is off somehow…
Look at all that empty white space! Such a waste, but showing each item in a row is what the list view does. Sometimes, that may be exactly what you need in some cases but here…we don’t need it.
Instead, we can use the “Gallery” (or “Tile)” view, which will display our items in a grid view.
We can copy the the schema we’ve already defined, and change the selected layout from “List” to “Gallery”
After that, we can paste it in, but we’ll need to modify things every so slightly, as the Gallery layout has some additional properties we need to specify. Let’s look at the basic schema for a gallery view.
{
“$schema”: “https://developer.microsoft.com/json-schemas/sp/v2/tile-formatting.schema.json”,
“height”: 175,
“width”: 650,
“fillHorizontally”: true,
“hideSelection”: true,
“formatter”: { }
}
Unlike columns and list view formats, the tile schema wants us to specify an exact width and height (in pixels) for each tile. It’s not strictly required, but we’ll want to supply our own values here to ensure that each card has the right dimensions.
We’re also using a new property, fillHorizontally, which will ensure that our cards do not overlap one another.
Finally, instead of the rowFormatter object we use in List views, we have a simple formatter property for our Tile views.
After that, we can simply copy the contents of the rowFormatter property in the list view example and paste them into the new formatter property.
Doing that should get us to where we want to be.
Prologue
Over the course of two blogs, we’ve covered the basic building blocks of custom column formatting as well as how to customize our list and gallery views. We turned a boring old list of text into far less boring visuals, and then turned those visuals into a “who’s who” of Middle Earth.
And while our journey together might be coming to an end, it doesn’t mean your adventures are over. Take what you’ve learned, go out into the world, and make your lists beautiful!
Recent Comments