Software Checker

In an enterprise, it is common to have hetergenous environments like 'IVE', 'OnTheGo', each employee could have different version of browser, different java or Flash plugins. In such environment, it is difficult to ensure that the application(starting 5.8.5 Flash is used) or content that is created by different vendors runs properly.

From 5.8.5, LMS introduces a nice feature called "Software Checker" to address this. This checks for the browser and plugin compatibility and alerts the user about it and also helps them in downloading the required version of software.


By default, the software checker does not check for users' version of Flash Player. You can turn on Flash Player checking by updating the PS_SUPPORTED_SOFTWARE table. Customers should change the ACTIVE flag to Y where SOFTWARE_NAME = Flash. This causes the software checker to check for browsers' versions of Flash Player.

You can also turn the checker completely off for users and administrators in Talent Management Administrator. Go to: System Admin > Configuration > Global Variables > Enable Software Check for [admin/user].

Data Migration and Mastery Score

Here is the problem that one of the clients faced. The client had 2 different LMS versions running and wanted to merge the 5.8.3 data to the one in 5.8.5.

The data migration scripts were written by a Migration Expert and the data migrated. During the Customer testing of the content, the content was getting launched and they could complete the Course but it was not being removed from the Learning Plan and cannot be seen in the Learning History.

After debugging, I found out that the Mastery Score was null. This value was not being migrated from the 5.8.3 system based on the data requirements provided by the LMS Admin. When this value was set and the Course taken again then the Course moved to the Learning History. The 5.8.5 LMS application does not warn or throw an error mentioning that this field is null. Neither is this a mandatory field.

Here are some best practices while doing the LMS data migration. You will save precious time of everyone and thousands of dollars if these are followed.

• Data is the king. Data was entered for some purpose. So, without second guessing migrate the data as it is. The LMS Admins may not know why some field is required.
• Use the Copy Entity Tool to do this. This is easy to configure and it does not increase the time or cost to copy all the columns in a given table.
• Avoid writing SQL scripts to do data migration where Copy Entity Tool can serve the same purpose. 
• Get the data migration strategy reviewed by the Plateau LMS Consultant. 

Re applying a DB Patch

If for some reason, you are not satisfied with the DB Patch and want to apply it again, you cannot do it out of the box. Here is what needs to be done.

• Query PS_PATCH_INFO table and delete the records that have the Patch# that you want to re apply.
• Now run the installer again. This will install those patches again.

Applying DB Patch

Since SP4, the applicaton of DB Patches has improved. Following are some features

• The PatchInstaller(dry run mode) checks if any configuraton files that are beng delivered in the Patch are modified by the Customer or not. 
• If so, it lets the Customer merge the changes and update the DB (merge run mode)   

Note: Please verify if the files have been uploaded correctly. Check the timestamp in the DB. I know of one instance when the DBA applied the Patch, the Patch number has been updated correctly but the Report libraries were not updated. It is always a good practice to ensure that the files have been uploaded correctly. If not, these problems only appear during the testing or usage when it would turn to be very costly. The Application Patch version which is stored in PS_PATCH_INFO table showed all the patches applied correctly.

Many Customers are of the view that the upgrade can be done only by the Vendor. This can also be done by a Plateau Consultant or by a DBA with guidance from LMS Consultant as the DB scripts are very straightforward to apply the Patch. Once it is done in house then the costs of further upgrades that are required in different environments can be done as and when required. This saves a lot of time, cost and helps in  planning the project better.  

Budget and Quality - Managing the LMS Implementation effectively

Companies that approach me for the LMS solution come up with the following experience they had with the previous vendors

• The implementation cost has overshot the budget by at least twice the budget
• The quality of the implementation

I found the following common problems in the above implementations

• The Vendor over charged for the LMS implementation and delivered a poor quality implementation.
• Waterfall Approach followed in the execution of the projects. This approach conceals the problems in requirements, implementation, skills, budget till the end where there is  little room to make any corrections as the budget had already been overshot. 
• The source code for the integration is not available to the Customers and as a result they are tied up with the costly solution provided by the Vendor.

Here is how I propose the above to be solved. Of course, this has to be discussed with the Customer and they have to be comfortable with it.

• Get the fixed cost bids from a few vendors and compare them
• Follow the Agile methodology. This ensures the integration is done in multiple iterations. This will help flush out the requirements, continously tests the quality of the implementation, helps in prioritizing what needs to be done, helps in controlling the budget. This is a change in the mindset for which the Customer and Vendor need to be ready to work with.
• Ensure that the Vendor provides the source code of the Connector as this will reduce the cost in upgrading to new versions and in customizing the solution.

There are other problems that I have observed which the Companies should be aware of

• This is a technical problem and needs strong technical folks with Plateau LMS SME knowledge to head this effort. Do not rely on the non technical managers who may be the SME in this.
• Get the Content right. Prioritize this for the beginning and ensure that different types of Content(AICC, SCORM) can be launched and the run time communication works well.
• Ensure that you get the setup of Domains right and automated.
• Ensure that any data transformation is externalized.     

Deployment

The desired deployment scenario is as follows

1. Web Server - This is the gateway to the LMS. The static files(images, styles,etc) are deployed here. All requests are from here. This could be Apache HTTP Server.
2. Application Server - The LMS application is deployed at an Application Server(Weblogic, JBoss, Websphere).
3. Content Server - All content (AICC, SCORM) is deployed here. This could be a Tomcat Server.

Branding Styles

The Branding Styles are usually modified by an external vendor. The changed files are usually in styles and images. The deployment of these files is as follows

1. If the static files are deployed at the Web Server then these files just need to be copied over. This is the recommended approach.
2. If the static files are not deployed then they need to be copied in plateau.war which exists within plateau.ear and the ear needs to be redeployed.

Multiple branding styles can be created and they can be applied at Organization or Domain.

Secret Weapon - Copy Entity Tool

There is a less publicised tool by the name of "Copy Entity Tool". It is only published to copy selective data from the staging to the producton environments. But, to a Consultant who knows about customizing it, this can be used to migrate data from one version to the other and to copy all the entities from one schema to the other. This can reduce a lot of migration cost to the Customers.

Merging of Users

There would be scenarios when an employee changes the status from temporary to permanent and this results in the generation of new EmployeeID(User ID) in the ERP system.

There could be scenarios where the User IDs in LMS are not in sync with the User Ids in the ERP system. And one fine day, the management wants these IDs to be in sync.

To overcome the above 2 scenarios is not difficult. There is a "merge" user feature that is available in the LMS. This takes the old user id and the new user id and merges all the relevant records to the new user id and inactivates the old user id. Movng forward, the new User ID would only have a new ID but will have all the old training information. If there are very few records that have to be merged then this could be done manually by the LMS Admins. If not, the Connector application needs to be extended to do this merging.

plateau_client.jar is out of sync

The plateau_client.jar is provided in the LMS release for the client applicatons to connect to the API. This has the interfaces, stubs and ValueObjects to invoke the APIs remotely or locally. But in SP5 this is not in sync with the code base.

The workaround for this in 5.8SP5 is to use the plateau_sp5.jar that is in the EAR file. But this went out of sync when the application was upgraded to 5.8SP5 P14. The solution for this is to upgrade the plateau_sp5.jar. This can be done by the LMS Consultant or a request has to be made to the Plateau Services.

How to create Domains in LMS

Domain is a very important entity in the Plateau LMS. The whole security(record level access) is based on the entity(user, item, curricula, question, etc) belonging to the Domain. The LMS Admins are assigned Roles that comprise of workflows which are restricted to specific Domains. So, the LMS Admins have access(read/write/search/view) to all entities that belong to the restricted domains.

In most organizations, the source data of Organzation and Users(Employees) is maintained by the ERP system. These systems have no knowledge of the Domains. So, a common question that comes up while setting up the system is the creation of domains, the security and the mapping between the Users and Domains.

There could be many solutions to this based on the way the Organizations are setup in a Company, how the LMS Admins are tasked with managing the Users, etc. I shall go through one scenario that I have come across which may be prevalent in other companies and my proposed solution for this.

The Organizations in the ERP system are setup at each JobPosition which has direct reports. So, this leads to an Organizaton tree spanning around 9 levels deep starting with the CEO. Setting up the domains in such a scenario is tough if the access to the LMS Admins should be at the Organization level. If this is done manually then maintenance of this system will become more than handful for the LMS Admins when there is change in the Organizations.

My proposed solution is to create a Domain for each Organization automatically by the Connector when it synchronizes the Org and User data. Following are the advantages of this solution

• The access to the LMS Admins can be provided at the Organization level
• I have seen some solutions which have an Org-Domain mapping table in the ERP system which has to be maintained. This solution does not require any mapping table and zero maintenance.
• The users of a newly created Organization can access the system as soon as the Connector is run and need not wait for the LMS Admins to manually make the changes in the system.

The disadvanatges of this solution are

• The Domains are created at the Organization level. If the LMS Admins can only manage users based on the location and if the Orgs span employees across locations then this solution does not work elegantly. Some work arounds like Saved Seraches and Saved Reports have to be applied to make this work.