[tabs slidertype=”top tabs”] [tabcontainer] [tabtext]Transcript[/tabtext] [/tabcontainer] [tabcontent] [tab]

System Module Global Configuration

0:06
Welcome to this IT Explainer video, part of our System Module topic range.

0:10
In this video we will cover the subject of Global configuration in SLMA.

0:16
Global configuration in a software application refers to a set of settings that apply universally across the entire application, rather than being specific to individual users or instances.

0:29
These configurations typically control core aspects of the system’s behaviour and functionality, such as environment settings, user interface defaults, security settings, performance parameters, feature flags, and integration settings.

0:45
The following information will be covered in this training.

0:47
Chapter one will be environment settings.

0:50
Chapter 2 will be interface defaults.

0:53
Chapter 3 will be performance parameters.

0:56
Chapter 4 will be Security Settings and Chapter 5 will be User module settings.

1:06
In Chapter 1, we’ll cover understanding the environment settings utilised by SLM.

1:12
In SLM, global configurations are found in the System module under Global Configurations.

1:19
Here we will find environment settings, interface defaults, performance parameters, security settings, and user module settings.

1:29
The Enable Audit logging will log important interactions in the application, specifically in the System module.

1:37
When this is enabled, an audit file will be created under the Audit log path folder.

1:44
If we go to the Audit Log path folder, we can see that there’s no files created yet.

1:56
So let’s go ahead and enable this variable.

2:01
Now it’s enabled.

2:01
Let’s run the command again, and we can see that a file for the year and the current month has been created, a CSV file.

2:10
If we open this file, we’re going to see the format of it.

2:19
It has an action date, action by context, type, subtype, component description, and request URL.

2:26
So if we close that now, let’s go to a dropdown.

2:33
Let’s modify one of these.

2:35
Let’s create a new option.

2:38
We’ll go for test the value of test list order of three.

2:42
Click save.

2:44
Now let’s go back to the file.

2:47
We can see we have an entry in here in the audit file with the date, the action by context.

2:56
The type will be drop down options.

2:59
The subtype will be BOP acceptable which was the drop down ID.

3:04
The component is test and the description is drop down option added and we’ve got the URL.

3:11
If we come back and we delete this option we created and save changes, we open the file again.

3:21
We can see this new entry in here and we can see the description is drop down option deleted.

3:30
When Bypass and User License Agreement is set to NO, it forces users to accept the licensing agreement the first time that they log into SLM.

3:40
Let’s see an example of that now.

3:47
Once the user logs in, before being able to access any modules, the user needs to accept the agreement.

4:01
Now if we set this value to yes, which means we can bypass the license agreement.

4:07
If we come back here & out & back in again, then the user can come in here and access any modules that are enabled for the account without having to accept any end user license agreement.

4:27
The Document Management system file path is a folder where the physical documents attached to an object are going to be stored.

4:37
Let’s take a look at the current folder.

4:40
Currently it’s empty.

4:43
Now let’s attach a document.

4:49
We’ll call it Test Document.

4:56
Let’s upload a PDF file and click on Save.

5:00
If we come back to the folder again and run the same command, we can see the PDF file that’s been uploaded.

5:10
The system translates the name of the PDF to an encrypted name, so they’re not readable.

5:16
Now, if we come back to the application, we can download the document with the encrypted file name.

5:24
The license e-mail request variable will hold the e-mail address where administrators will receive licensing requests.

5:33
So let’s go over an example.

5:34
Currently the system is using A1 concurrent user license.

5:38
So we’re logged in with one account.

5:41
Let’s go and log in with a second account and we can see that the license limit has been reached.

5:48
So if we now submit a message, it will be sent to the e-mail address that we saw earlier.

5:54
Let’s say need one more license and click submit.

5:59
We can see here where the license e-mail request will be sent.

6:02
So if we come to our inbox, check that e-mail, we can see we received an e-mail from the user test saying that we need one more license.

6:12
The next variable that we’re going to go over is the license path.

6:16
Currently the license path is pointing to the licenses folder, which is currently empty.

6:24
So now if we upload a license, select files and open that and save, we now have a license file in here.

6:36
If we look at the environment settings, we can see the path here is slash licenses.

6:44
So if we come back in here and rerun the command, we can now see that we have a license file in here.

6:52
SLM keeps track of every request that every user makes on each module in the SLM application.

6:58
Let’s take a look at this log.

7:01
The log will contain the access time, which account has done it, if it’s an embedded call or not, which module, which platform, browser version, the requested Uri, the method, whether it’s a POST or a GET, alongside a few other fields.

7:18
So SLM keeps track of this for auditing purposes.

7:21
Now there’s a variable in the environment settings that will hold a value for delete usage log after a certain amount of days, which is currently set to 30.

7:30
So after 30 days, those log files will be deleted.

7:34
The delete trash notifications after value will delete any notifications that are older than this value set here.

7:41
So for example we have 30 days set here.

7:44
So any notifications that are older than 30 days will be deleted.

7:49
The notifications can be found up here in the notification system and those that are deleted will be moved here to the trash.

7:56
The delete finished tasks after value will specify the number of days old that a task has to be in order to be deleted again.

8:04
In this scenario, we’re set at 30 days.

8:07
So if we go to the background task manager and the background queue monitor any of these tasks that are finished that are older than 30 days, they will be removed from this table to keep everything clean.

8:19
The SAML configuration path is the location where all of the SAML configurations will be stored.

8:25
So if we take a look at the server here, we have the configuration for SLM Gold in slm.com.

8:33
The value in the Support e-mail recipients variable is the e-mail that will receive the notification when a user submits a request through the Contact User Support section.

8:45
Once the support ticket has been submitted, we can go to e-mail and we can see the e-mail address where that request has arrived.

8:53
The support phone number is the number that you would like users to call with any SLM requests.

8:59
The temporary file path is a folder where all of the temporary files are going to be stored for SLM.

9:04
So let’s go to the server.

9:07
Let’s go to temporary files.

9:10
So we can see the temporary files that have been created so far.

9:13
In here, the usage report path is a folder where all of the usage reports will be stored.

9:20
So let’s go to that folder.

9:28
So far, we don’t have anything stored in there.

9:30
So now let’s generate a usage report.

9:34
Let’s go to licensing usage details, update report.

9:39
Let’s wait until that report is generated.

9:42
Once the report is generated, users can download the report.

9:56
And then we can go ahead and rerun this command and take a look at the folder.

10:01
We can see that we’ve generated a usage report in here, and it’s stored in this file path.

10:06
The user revision system variable is set to Yes.

10:09
Objects in any module will have the revision tab visible.

10:13
If we set this to no, that tab will not be visible any longer.

10:16
So let’s go to a module.

10:18
We’ll go to Instrumented Systems.

10:20
We’ll select a SIF.

10:23
Here we can see the Revisions tab.

10:27
We can see all the revisions in here for this object.

10:30
If we now come back and set the variable to no and click on a different tab to refresh, we can see that the Revisions tab has now disappeared.

10:44
The video file sharing variable is where any training videos are going to be stored in this scenario.

10:50
This instance doesn’t have any training videos, so the value remains empty.

10:56
In Chapter 2, we will cover understanding the interface defaults utilized by SLM.

11:02
Now let’s take a look at the interface default settings.

11:06
First one will be Fontfamily.

11:09
If we edit this variable, we have Verdana, Helvetica, Sans Serif, Roboto, and San Francisco.

11:20
Let’s just change it to San Francisco and click Save.

11:24
Once we change it, if we refresh the interface, we’re going to see that the font has changed.

11:31
Let’s change it once more to Sans Serif.

11:36
Let’s open a different tab this time so we can see the difference here between the two fonts.

11:44
Other variables for the interface default settings are the body font size.

11:49
Also for headers we have font size for H1H2H3 and H4 and font weight.

11:56
Let’s change all of these and see how it affects the interface.

12:00
So we’ll change the body to 14, header ones to 24.

12:12
We’ll increase them all by 4, so 20 for header twos, 18, 16 for headophones, and for the font weight, let’s go for light so we can see the difference.

12:43
So we have two tabs here with versions of SLM.

12:46
So right now they have the same fonts.

12:47
So let’s refresh the one on the right and we can see the H1 tag has increased in size.

12:58
Same with header 2, header 3 and header 4.

13:01
The font size of the whole application has increased and the font weight is no longer bold.

13:07
The translate variable enables or disables the translator in SLM.

13:15
Here we can see we’ll change it to Arabic back to English again.

13:26
So currently it’s set to Yes.

13:27
If we disable the variable and refresh the instance, we can see that we no longer have the translator variable in the top toolbar.

13:38
The Always Show Default Views variable is a setting that shows the default views for each object in SLM.

13:45
Default template will contain all fields for the object data type.

13:49
So let’s take a look at this scenario.

13:51
Let’s go to Instrumented Systems.

13:54
Let’s go to a function.

13:58
Currently there’s no default view or template, so let’s enable this variable.

14:05
Click Save.

14:08
Come back to Instrumented Systems.

14:10
If we refresh the instance, we can see we’ve got a tab here for default SIFT view, and it has the information for all of the data fields for the SIFT data type.

14:28
It contains related documents as well as children for the current object.

14:39
If we come to a unit, for example, scroll across and look at the default unit view required data, the recommended data, optional data, related objects.

14:55
These are the children of the object.

15:01
And then if there’s related documents, another variable that we have in the interface default settings is always Show Revisions view currently set to Yes.

15:13
So let’s come to the global module, come to unit.

15:20
We can see we have the Revisions tab for this object.

15:24
So let’s go back and disable this variable, click save, come back and refresh the view.

15:35
We can see the revisions tab is no longer visible.

15:39
Let’s enable it again.

15:46
And we can see revisions again.

15:52
In Chapter 3, we will cover understanding the performance parameters utilised by SLM.

15:58
For the performance parameters, we have Google Analytics ID.

16:02
In order to enable Google Analytics settings, an administrator will need to provide a Google Analytics ID for the application.

16:11
Let’s take a look at the Google Analytics dashboard.

16:14
It provides insights into users behaviour, traffic sources, audience demographic, and help businesses improve the user experience.

16:26
In Chapter 4, we’ll cover understanding the security settings utilized by SLM.

16:32
Under security settings, we will find the Amazon Simple E-mail Service variables.

16:38
These variables need to be configured in order for SLM to submit emails while using Amazon SES as the e-mail service.

16:46
The four variables that need configuring are SES Key, SES Region, SES Secret and SES version.

16:55
Let’s just update our profile.

16:58
Let’s clear the data, which in turn should generate an e-mail.

17:03
So in here we can see an e-mail specifying that the profile for this account has changed.

17:09
The Max failed login attempt is the Max number of failed login attempts before the account is locked to prevent brute force passwords guessing attacks on the application.

17:19
So let’s go over a scenario.

17:21
This variable is set to three, so let’s now input the wrong password three times.

17:33
Now if we try for 1/4 time, we can see that the account has been locked and the user has to reset their password.

17:43
Now if we go to Manage User Accounts and search for that account, we can see that that account has been locked.

17:54
The Create SSO accounts for Authenticated SSO users will automatically create an SLM account for those SSO authenticated users.

18:03
This will save administrators having to create every single SLM account for users that are already authenticated by an IDP.

18:10
So let’s go over a scenario.

18:11
Currently the value is set to NO.

18:13
Now let’s try to log in with an IDP authenticated user.

18:18
As we can see, SLM does not allow the user to log into the application because there is no SLM account created for this user yet.

18:26
Now let’s go ahead and change this variable to YES.

18:34
Now let’s try and log in again with the IDP authenticated user.

18:39
As we can see, an SLM account gets created automatically.

18:45
The user is able to log into SLM.

18:48
The local login disable variable disables users from logging in using a username and password.

18:54
So the only way for users to gain access to SLM is through SSO authentication.

18:59
So if we try to login with different account, this is a local login.

19:09
We disable the local login.

19:17
We can see that there’s no longer an option to enter a username and password.

19:21
The only way to log in is using SSO authentication.

19:25
Domains allowed refers to HTTP refer validation and domain whitelisting, which are commonly implemented as part of application security measures.

19:36
This variable serves to define a list of trusted domains permitted to send requests to SLM.

19:42
It’s often utilized in Cross Origin resource sharing and is essential for enabling Single Sign On SSO with Identity Provider IDP federation.

19:53
By whitelisting domains, authentication responses are restricted to only those recognized IDP’s or trusted services.

20:01
So let’s go over a scenario where we are restricting requests from the application only.

20:06
When the variable is configured to allow only requests from within the application itself, external authentication attempts will fail, preventing login.

20:15
So let’s go ahead and try to login.

20:19
As we can see, we’re not able to log into the application because the identity federation domain is not whitelisted in the domains allowed.

20:28
Now if we add the federation domains.

20:36
Authentication requests from the specified ID PS are accepted, enabling successful login.

20:43
Now let’s go ahead and try to login again.

20:50
As we can see, SLM is accepting requests from the Identity Federation domains and we’re able to login successfully.

20:58
Idle Time Enabled and Idle Max time are two variables that work together when SLM is using a concurrent license agreement in order to log out those accounts that have been inactive for a certain amount of time.

21:11
In this scenario, we can see we have a value of 1.

21:14
So the system will check if there is an account that has been inactive for a minute or more, and when that account tries to do something else in the software, it will be automatically logged out.

21:23
So the user will have to log back in again.

21:26
Let’s have a look at a scenario.

21:28
So if we log into SLM with a test account.

21:38
So let’s say the user is navigating through objects.

21:43
If we now leave the system idle for one minute.

21:48
OK, so a minute has now elapsed, so let’s now try and navigate somewhere else within SLM.

21:55
And now the system has logged the user out and we need to log back in again.

22:00
The E signature enabled whenever it is set to true will work in conjunction with E signature token expiration.

22:11
These two variables are used when a user that is an approver is going to approve an object and the system will request for a token to be submitted via e-mail or text.

22:21
Once the user inputs that token, the object will be approved.

22:26
Now if the user takes longer than this amount of time, the three minutes to input the token, then the token will expire and the object will not be able to be approved.

22:36
So let’s take a look at a scenario.

22:38
Let’s say that we have this demand event that will be submitted for approval to approve a number one, let’s click submit.

22:47
Now let’s go ahead and approve the object.

22:49
The system will require the user to select the E signature method, e-mail or text message.

22:55
So let’s select e-mail and click next.

22:59
Now the system requires the token, which is 2 numbers.

23:02
So let’s go to our e-mail, and we’ve received an e-mail.

23:07
So let’s copy the token.

23:12
And the second part, we can see that this token is set to expire in 3 minutes, which is the number of minutes that we set in the variable for the configuration.

23:27
Let’s now click save.

23:31
And now we have approved this demand event.

23:35
When creating a new password or resetting a password, there are three variables that can be configured in the system.

23:41
1 is the password lifetime, and that’s the number of days a current password is active for before it must be reset.

23:49
If this value is set to 0, this means that the password will never expire.

23:53
Then we have restricted password reuse.

23:56
If this is enabled, users will not be able to reuse any old passwords.

24:00
When they change the password, it will have to be one that hasn’t been used before.

24:04
If it’s not enabled, the only password that won’t be allowed to be reused is going to be the last password.

24:11
Minimum password size.

24:12
This is the minimum number of characters that the password has to be.

24:17
The SSO button text is going to be the actual text that the SSO authentication button will show at the login screen.

24:24
Currently it says Login using Mangan Google Apps account and here is the text.

24:38
In Chapter 5, we’ll cover understanding the user module settings utilized by SLM.

24:45
Under the User module settings, the first configuration that we find is automated event modules.

24:52
This value will hold the ID of the module where AER events will be able to be seen.

24:58
Currently, it’s shown in the OMI module.

25:02
So let’s go to the OMI module.

25:05
And also we need to enable that in our profile Arkansas notifications.

25:13
So let’s go back to operate and maintain.

25:15
Now we can see this icon at the top here.

25:20
If we click on that, it will take us to the automated event records.

25:26
Now if we change this, let’s say, to Instrumented Systems module, let’s refresh on the operate and maintain and the icon doesn’t show up.

25:38
If we come to Instrumented Systems, now we can see the icon within Instrumented Systems and we’re able to see the AER objects in this specific module.

25:50
The user applicable IPL calculation is a flag that is used to enable or disable barriers that are related to functions in the local worksheet based on the function status.

26:01
So let’s look at a scenario.

26:04
So we have this local worksheet with initiating calls and in this scenario there is a barrier that’s been applied.

26:16
If we take a look at the barrier, the barrier is related to a function.

26:22
This function is coloured in red because certain function conditions have not been met.

26:27
If we take a look at the function we can see the designed demand rate is lower than the actual demand rate for the function.

26:35
Setting the status of the function to non operating.

26:39
Now, since we have this variable set to NO, the system is not concerned with whether the barrier is related to a function that is operating or not.

26:47
Hence, the barrier will show up in the local worksheet and it will be taking credit in the local worksheet calculations.

26:55
Now if we change this value to YES, then we come back to the local worksheet and refresh applicable values, we can see that the applicable IPL has disappeared.

27:13
The barrier is no longer visible since it’s related to a function which has a non operational status.

27:21
The bypass tier settings indicate what type of bypasses are going to be considered to calculate the time and service for a function.

27:30
The possible values for this if we come into here, bypass authorisation, bypass activation or both.

27:38
Let’s take a look at how the system behaves when the bypass tier settings is set to bypass activation.

27:46
We come to operate and maintain come to the unit level and we come to the bypass status sys template.

27:52
This template will display only bypass activations recorded in SLM.

27:57
As we can see, we have SIF 001 with the bypass activation, which is the one that we have right here.

28:05
Only bypass activations are going to be considered for the function availability calculation.

28:11
So if we go to the function and we check the Tier 3 metrics, we can see the availability of 64.5% when the system is using the bypass activation based on the bypass activation date.

28:24
Now let’s go ahead and change the value to bypass authorization.

28:30
Now let’s go back to the unit bypass status.

28:38
Now we can see a bypass authorisation that was approved on November the 29th, 2024 and the grids are currently only displaying bypass authorisations.

28:50
Now let’s take a look at the availability for the function.

28:53
If we come to the Tier 3 metrics again and we can see that the availability has decreased, now we have an unavailability of 87.1% and that’s because the bypass authorization was created closer to the Commission date of the function.

29:11
Let’s now go ahead and change the status value to both.

29:14
At this point, the system will display both types of bypasses, authorizations and activations.

29:31
And then when we check the function availability in the Tier 3 Metrics tab, the availability is still 87.1% because the bypass authorisation is the oldest bypass in this function.

29:44
The Use PDF or RRF for calculations flag will take two values, either PFD or RRF.

29:52
The system can either use RRF values and derive the corresponding PFD values or use PFD values to compute the RRF automatically.

30:02
These fields are located at the SIF function.

30:05
So let’s have a look at a scenario.

30:07
So currently the value of the variable is RRF, which means that the RRF is the value that’s going to be calculated.

30:14
Hence the PFD is the only value that can be modified.

30:19
So if we modify the value to .3 and click save, calculating the inverse of the PFD value will calculate the RRF.

30:28
Now if we change this value to PFD which is going to be the calculated value.

30:38
Now users will be able to input the RRF value and the PFD will be automatically calculated.

30:54
Enable Enterprise Project.

30:55
When set to YES, the project module will be enabled and also the project features.

31:02
So we can see here we have the Enterprise project module under the special modules and currently this account has access to the tutorial project.

31:15
If we go back and disable this and then we refresh SLM, we can see that this account doesn’t have access to any projects and we cannot see the Projects module any longer.

31:32
The likelihood source is a variable that is used by the HAZOP studies to get the likelihood from 2 possible sources, which is going to be the HAZOP cause or the HAZOP scenario.

31:43
Let’s look at a scenario where the HAZOP is getting the likelihood from the HAZOP cause.

31:47
If we come to the HAZOP module, we come to a HAZOP study.

31:52
We have 3 scenarios in here, two of which have the same cause.

31:56
Call 001 and call 002.

32:00
If we come and manage the causes, we can see that cause one has a likelihood of one and cause 2 has a likelihood of two.

32:08
As we can see, the two scenarios using a cause one have a cause likelihood of one, and the scenario using cause 002 has a cause likelihood of two.

32:19
If we change the cause likelihood to a value of three for this scenario and click Save changes, the likelihood changed on the second scenario as well because the likelihood is being updated at the HAZOP cause and these scenarios have the same cause 001.

32:35
And this is the value that’s going to be used towards the HAZOP calculations as well.

32:39
If we go and take a look at managed causes, we can see that cause 001 now has a likelihood of three.

32:47
Now let’s go over the second option for the likelihood source.

32:50
We’ll change to scenario.

32:55
Come back to the Hazop module.

33:00
Let’s refresh the template.

33:02
As we can see, the likelihood currently has empty values for each of the scenarios.

33:07
Now this time the likelihood source is going to be from the scenario.

33:11
If we select 5, for example, we can see that cause one has a likelihood of five.

33:18
But for the second scenario that’s also using cause one, we haven’t got a value set in here because the value doesn’t affect the likelihood of the cause, only the HAZOP scenario.

33:28
We can also observe this if we come to manage causes, we can see the likelihood for cause 1 is going to remain as three because we’re using the likelihood of the scenario.

33:44
Let’s come back and just change the likelihood source to cause again.

33:52
We refresh, we can see that the values being used are the ones from the HAZOP cores, which is free for cores 1 and 2.

34:00
For cores 2, the overall LOPA sheet RRF calculations can hold free values individual, hybrid, and summing.

34:12
If the value is individual, the overall RRF calculation for the local worksheet, we’ll get the maximum value of the LOPA gap scenarios.

34:21
The summing we’ll sum up all the LOPA gaps for all of the scenarios in the LOPA worksheet, and the hybrid will use the individual method.

34:29
If the LOPA RF is no greater than 10, once it’s greater than 10, it will take us to a default summing method.

34:37
Let’s go over a scenario so we can see the difference in the free values.

34:41
So let’s start with individual.

34:43
We can take a look at this local worksheet in the local module.

34:47
Let’s take a look at all the Loper gaps for this local worksheet.

34:51
Scenario one has one, scenario 2 has one, scenario 3 has one, and scenario 4 has 10.

34:59
So the maximum value for the Loper gap of all of the scenarios is going to be 10.

35:05
So if we go to the summary template, we can see that the Loper gap will be 10.

35:11
Now let’s go over the summing value.

35:19
In order for this to trigger we need to make a change.

35:25
Let’s say that we apply a conditional modifier and save changes which will reduce the gap and set it to one.

35:33
Now the summing will sum all of the gaps for all of the scenarios.

35:37
In this case we have 111 and one that would be 4.

35:43
So if we go back to the summary template and we refresh, we can see that the lope A gap is now set to four.

35:52
Now let’s go to the hybrid method.

35:58
The hybrid method will behave the same way as the individual method, getting the maximum lope A gap for all initiating causes only if the sum of all of the initiating causes is less than 10.

36:11
In this scenario, we have a value of four, which is less than 10, so it’s going to behave the same way as the individual flag.

36:21
Let’s just trigger this calculation.

36:27
So the value should be one because the sum of all of this is going to be 4, which is less than 10, so it should behave as individual.

36:35
So the system is going to search for the maximum value of all open gaps, which should be 1.

36:44
So let’s refresh the Lopez summary template, and we can see we have a lope, a gap of one.

36:50
What happens if we uncheck this conditional modifier?

36:55
So we should have a lope a gap of 10 now.

36:59
So if we sum these all up, now it should be thirteen, which is greater than 10.

37:05
So now we’re going to have a summing method.

37:07
So our value in the lope A gap should be thirteen.

37:12
So if we refresh the template, we can see that we now have a lope, a gap of 13.

37:18
The transpose Hazop DRM transposes the Hazop.

37:21
For the DRM, it’s currently set to no.

37:24
We have the severity on the left and the frequency at the bottom.

37:29
So if we enable this and we refresh the view, the axes has been transposed.

37:37
So we have severity at the top and we have frequency on the right.

37:42
The transposed looper DRM transposes the access for the looper DRM.

37:47
So let’s take a look at the looper dynamic risk matrix.

37:50
We have severity on the left and frequency on the bottom.

37:54
Now let’s go ahead and change the flag.

37:59
Refresh this.

38:00
Now we can see we have severity on the top and frequency on the right.

[/tab] [/tabcontent] [/tabs]