10x Technical Differences (Advanced)

Join RPI while we present Lawson 10x technical differences. Part of our Winter Webinar Wonderland Series, this updated webinar, Lawson 10x Technical Differences, is especially relevant to anyone on their way to 10x. Richard Stout gives an overview while going into:

• Ming.le/Sharepoint Integration
• Server Environment/Architecture
• Landmark
• IPA and ISS

Keith: I want to thank you for taking the time to attend this presentation on Lawson 10x technical differences. This is our second day of webinars this week. We’re very excited about today. We have a murder’s row of presenters presenting all day. A Mr. Richard Stout, one of our best presenters, is going to do technical differences. It’s a very advanced presentation. It’s one he’s been doing for about a year and a half and what’s really exciting about it, he’s always updating it and changing it. It pretty much looks nothing like the one that he was doing a year ago. He makes it a lot of fun. I’m very excited to see him. We’ll hand off in a little bit.

We also have Mr. Jeff House doing a presentation at 1:00 on deploying Self Service, Employee Manager Self Service outside the firewall. We have a very special guest today. Jeremy Stolfa’s talking about Landmark administration, and at the end of the day, we’re actually going to have a Landmark panel to take all your questions with Kathy Williams and Carl Seay, Richard Stout, Jeremy Stolfas, John Wade, Ashley Rhodes. It’s going to be a real exciting day. I hope you’re able to join us for all these webinars. Without further ado, I introduce Mr. Richard Stout.

Richard: Thank you. Thank you. Thank you, Keith. Thanks, everyone, for attending. Hopefully we can exceed the number of participants we had yesterday so I can win our office pool this week. Thank you for joining in for 10x technical Q&A, called a Q&A because I’d like to encourage you to ask questions along the way. Try and poke me, throw me off my game. I’ll ask my producers to interrupt me at any point during this presentation with any questions I’ll try and address right away. We are RPI consultants, 50 plus consultants nationwide. We have a strong technical team and we have had the great fortune to have had a ton of experience with Lawson 10 over the past two or three years, with many upgrades live over the past year.

Today’s agenda, we’ll talk about platforms and licensing. We’ll get into Mingle, because I know that’s a pretty big area of interest for Lawson 10, touch on ESS a bit, but my colleague Jeff House is doing an ESS focus presentation at 1:00 today, so if you’re interested in ESS, I would really encourage you to attend that. We’ll talk a little bit about Landmark, but I’m really excited about this afternoon’s Landmark panel. That’s at 4:00, so if you have any Landmark questions, you might want to hold them for our 4:00 Landmark panel. We’re going to touch on Infor standardized release cycle. We’ll talk through a typical upgrade approach. We’ll touch on some things that are unique in a platform migration and finally finish up with testing and training.

Let’s talk about some of the platforms that Lawson 10 runs on, continues to support all the platforms that were available with Lawson 9. On the Unix side, AIX continues to be the most popular with Solaris and HP Unix supported. Red Hat Enterprise Linux has been added into the mix. LSF 10 will run on Red Hat. IBMI continues to be supported and on the Windows side, we’ve seen a lot of interest in the Windows platform. A lot of organizations are thinking about moving to the Windows platform and very interested in Windows server 2012 R2. I know that there are some organizations out there that got caught behind the Microsoft release cycle with running Windows 2003, so they’re very interested in building on the latest version of the server that’s available out there. All of the Infor server products are now certified to run on Server 2012 R2.

One thing, if you’re in the planning phase of your upgrade, really, even if you’re just thinking about doing an upgrade sometime next year, haven’t really lined up a partner yet, or put together too much of a project plan, one thing you can really get started on now is lining up your software licensing. That’s talking about the application decryption key for the 10x apps. If you’re adding Landmark into the mix because you have Process Flow, that requires a no-charge contract addendum to be executed within Infor, so that way your Landmark applications show up in your product downloads. If you’re moving to Server 2012 or Server 2012 R2, Micro Focus has changed the COBOL compiler for that platform. Rather than Net Express, they have replaced that with Visual COBOL and you do need to re-license your COBOL compiler, if you’re moving to Server 2012, Server 2012 R2. Your Infor account exec can facilitate getting a quote for the new Micro Focus product.

Other things to gather is your BSI support credentials, and don’t forget operating system and database licenses. The Lawson 10 platform now has components that are mandatory for the Microsoft Stack, we’re talking about Mingle, which has a requirement for a SQL server, so if you don’t already have SQL as part of your Lawson 10 mix, look at adding that and the licensing implications for that.

Let’s talk a little bit about user interfaces for Lawson 10. There are two main end user interfaces. The web user interface component is Mingle. This is the replacement for Portal. It was the … You might have heard it called Workspace. Workspace was the former name, now called Mingle. That’s your browser delivered interface. The thick client interface, the interface that you can install on your computer is Smart Office. Of course, you’ve all heard by now that LID is no longer supported for end users. LID continues to exist for administrative functions, but you can’t go to forms anymore.

Here’s a screen shot of Lawson 10, so if you haven’t seen it before, here’s what it looks like. Here’s our PO20 screen and of course it’s very recognizable to Portal. It’s basically the same fields in the same place. We still have our action buttons at the top, add, next, freeze, inquire, release. The color scheme is a bit different. We’ve got a few differences here. Our bookmarks, rather than being a menu that always hangs over on the left side, the bookmarks come in as a drop down now. Generally, the Lawson 10 web interface is fairly similar to how it looked in Lawson 9, especially in terms of functionality. A common misconception with Mingle is that all of your Lawson web-based contact is coming through or provided by Mingle. In fact, Mingle simply acts as a frame to our Lawson web applications. While the top of my screen here is actually coming from the Mingle server, powered by SharePoint, this acts as a frame for my content. The middle portion of the screen is still coming from the WebSphere application running on LSF that provides Portal.

If you’re in a … running Lawson on a Unix environment, you actually have content coming from two different technology stacks that’s brought together in the browser for a cohesive application experience. The end user doesn’t realize that the content they’re seeing on their screen, the top portion of their page is all powered by Microsoft, Mingle, SharePoint, backed by a SQL repository, but the transactional portion of the page, where you’re actually doing your work has a very similar architecture to how it worked in Lawson 9. You’ve got Portal.jar that’s deployed in web sphere, and you’ve got a Portal web server, either running on the LSF box or potentially running as a separate machine and all that content comes together. What that means from a performance perspective is that while Mingle comes into play for initially logging into the system and navigating into our Portal pages, once you get into Portal, Mingle takes a backseat and most of your interaction between the user’s browser is occurring directly with our Portal web server and with our WebSphere applications.

Let’s take a look at what are the components of Mingle. Here is my attempt at a conceptual diagram of the various pieces that make up a Mingle server. If I were to install Infor Mingle, I’d start by taking a Windows virtual machine and I’d first install SharePoint Foundation 2013. This is a free version of SharePoint available from Microsoft. It has to be installed in ‘farm mode’ and that means it uses SQL Server as a repository for configuration data. It won’t work with SQL express. You need to have a real licensed edition of SQL Server as the back end. It doesn’t have to be a dedicated SQL server, but it does need to be a real licensed version SQL Server. Once I have my SharePoint Foundation set up and running, the next step is I’m going install Infor Mingle Foundation and that’s the Infor product that installs into SharePoint and converts my SharePoint instance into a Mingle instance. The next step, once I have Mingle installed and running, is, I’d like to set up single sign on.

When you think about SharePoint, when you first tried to access SharePoint in your browser, it pops up and you’re using your own password box and it asks you to authenticate and out of the box, SharePoint wants to authenticate with Windows authentication. It’s going to authenticate against your active directory. Although we might have our Lawson environment bound to AD for password validation, we really don’t want our Mingle server authenticating directly against Windows. We’d rather have Mingle tied to Lawson for a single sign on. In order to that, I need to replace the built in security token service that comes with SharePoint with an Infor component that will provide ‘Lawson as Security Token Service’ or ‘LS as STS’. That component installs out of a DSP.jar, which is available separately on the Infor product download site.

Once I’ve got Mingle up and running and single signing on to Lawson, at that point, I’m going to bring in my Mingle Plug-ins, which will bring in my various Lawson applications into my Mingle framework. I might have an S3 Plug-in. This is the most important one of course, is the one that brings Portal content into Mingle. That gives you your globe icon at the top of the Mingle screen. We also have Plug-in available for various other Infor web applications, such as LBI and MSCM and a custom Plug-in which allows you to bring in any Infor web application into Mingle. Yeah?

Speaker 3: We have a question from one of our participants. Does the free SharePoint use Kerberos or Enterprise or what for authentication?

Richard: Does the free SharePoint use Kerberos or Enterprise or what for authentication? There are three authentication schemes or methods available with Mingle, all three of which will work with the free SharePoint Foundation 2013. There are essentially no advantages or requirements to implementing Mingle on a paid licensed or a higher version of SharePoint beyond Foundation. All that gets you is the additional Microsoft SharePoint capability which you would probably not take advantage of in a Mingle deployment. The free SharePoint Foundation 2013 can be set up to run with LS as STS, it can be set up to run with ADFS, and it can be set up to run with Kerberos.

Our recommendation mirrors the guidance that Infor puts out, which currently says LS as STS is the simplest authentication scheme and it’s recommended to use LS as STS and unless you specifically want to take advantage of some of the capabilities available with ADFS or with Kerberos for a single sign on beyond the Lawson suite of products. Yeah.

Speaker 3: We have another question from a participant. Is it possible to have SSO with an active directory running?

Richard: Yes, it absolutely is. When signing into Mingle, when I try to access Mingle, even before I get to Portal, when I try to access Mingle, my LS as STS is going to kick in and redirect me to the Lawson SSO servlet. It’s very similar to how DSSO worked with Lawson 9. I’ll enter in my user name and password that the Lawson DSSO servlet, which is running on the LSF box, is going to authenticate me. At that point my LDAP bind is going to kick in. LASE is going to initiate a connection to my AD domain controller. It’s going to say, “I’ve got an authentication attempt here so that here’s the user name, here’s the password. Give me a thumbs up or give me a thumbs down.” My domain controller will then respond and Lawson will proceed with the log in.” You absolutely still can do password validation against active directory in this scenario, and that’s actually handled via the Lawson layer, rather than directly from Mingle. More Mingle questions.

Speaker 3: Yes. What if I’m using Lawson in the cloud? Is this still applicable?

Richard: Yeah, absolutely. One of the differences with the way the Infor cloud sweet is configured and deployed, is that rather than using LS as STS, they use the ADFS authentication scheme. Instead of having a direct bind where Lawson is connecting to the global catalog port on my domain controller, we have an ADFS component that’s a piece that installs into IIS on the Mingle box and of course you’d have ADFS services on your on premise network that that’s going to authenticate against. Carl will happily correct me if I have anything wrong there, as our Infor cloud technology expert.

Speaker 3: Richard, can you tell me how many servers are required for this diagram for each environment that you’re presenting at this time?

Richard: Yeah. Everything I’ve got here exists in one Windows virtual machine. This is one instance of Mingle. Then you see I have SQL Server here. SQL, you’ve got some options of how you’re going to use SQL Server with Mingle, and really there’s not a high usage of the SQL Server database for Mingle. It’s configuration data rather than transactional data. For licensing purposes, you might want to save on the number of SQL servers you have in your environment. You might want to share with an existing SQL server that are out there for other Enterprise applications. It’s up to you how you deploy SQL for your Mingle servers, but as far as number of Mingle servers go, our recommendation is one Mingle server per environment. If you have three environments, a test, a stage, and a prod, you’re going to want three Mingle servers, a test Mingle, a stage Mingle, and a PROD Mingle, and each of those Mingle servers should be on a dedicated virtual Windows machine. Cool. Let’s move forward.

All this stuff on Mingle … We touched on Portal.jar. That still exists, still runs, over on the LFS side. LBI renders a little bit differently in Mingle than how it worked with Lawson 9. With Lawson 9, if we think about LBI dashboards. It’s common to set up you EFS dashboard page as part of your Portal home page. You would see your bookmarks on the left, the search bar in the upper right and in the middle of the screen would an LBI dashboard. It works a little bit differently in Lawson 10, so we no longer have dashboards that exist within Portal content. Instead, dashboards come in a separate Mingle plug-in.

If we look back at our screen shot of Lawson 10, I’ve got a globe icon up here for my Lawson application and then I’ve got another icon up at the top that represents my LBI dashboards, and that’s how our user’s are going to navigate in between accessing the dashboards and accessing Portal content. A good news is if you used dashboards for navigation within Portal, all that is still going to work and be available in Lawson 10. You can have links on a dashboard that’s take you to a Portal forum. That’ll work and basically switch Mingle into the correct Plug-in and then bring you to the right forum you want to get to.

One other small difference is they got rid of the welcome message. Remember the welcome message in the upper right, which on a test environment is a great place to include the display of the product line you’re at. It might say, “Welcome Lee Stout tester or Welcome Lee Stout train.” That little area you can put a custom message, that doesn’t exist in Lawson 10. To overcome the inability to put your product line name there, there is an option to display the name of the product line right next to the token. Right next to where it would say, “PO20 purchase order”, we can turn on display that says, “PO20 train purchase order”, or “PO20 test purchase order”, so you can keep track of what product line you’re in, if you’re in an environment with multiple product lines.

Other cool stuff we can do with Mingle. We can publish a direct link to our S3, or Portal page. Out of the box, when you go to access your Mingle URL, that’s going to bring you to a SharePoint home page, and there’s not really much content out of the box on that page. You might find yourself, when you first have Mingle installed, that you’re navigating to your Mingle site, and then you’re immediately clicking on the globe icon to go to Portal. If you want, you can take that link that brings you to the Portal page and publish that directly on your intranet menu or however users are navigating in the system, so they can skip over seeing the SharePoint home page and go right to Portal. On the other hand, you might want to make use of that SharePoint home page. SharePoint is a great content management system. You can put some documentation up there or announcements, really make use of all the capabilities that are in SharePoint Foundation. You might find that is a great landing page to use for people accessing Lawson and stuff.

Other cool stuff we can do, we have this custom Plug-in functionality in Mingle. A custom Plug-in basically allows you to enter in any URL and then that becomes an icon at the top of the Mingle screen that’ll bring you to any page. What do we use that for? What Infor web applications would be great candidates to use a custom Plug-in for? One is RQC. If I have RQC for requisitioning, rather than having to navigate into Portal and then going into bookmarks, and then get to RQC, I can use a custom Plug-in to put an icon right at the top of my Mingle screen for RQC. All the Mingle Plug-ins tie to Lawson roles for security. If I have a role out there for requesters, I can tie my RQC Plugin into my requester roll and say, “Only show this icon, only show this menu option, to get to RQC if the user that’s currently logged in is in my requester role.

Another cool one, going along with requisitioning would be a req approval, so my web inbasket page, I can use a customer Plug-in, create an icon for approvals, and again tie that to my inbasketuser_ST roll, so only user who are approvers actually see that linked to get it.

Enough about Mingle. Let’s talk a little bit about ESS. Again, I do want to encourage you to go to Jeff House’s presentation at 1:00, where he is going to talk about new options for making ESS available outside the firewall. I will simply say that in the Lawson 10 world, it’s not supported to access Portal separate from Mingle. Your end users who are going in to do Lawson form based transactions. They need to be viewing Portal content through Mingle. However, ESS does not have that requirement. ESS pages, you are allowed to … It is a supported scenario to have your end users navigating in the various ESS pages outside of the Mingle framework. Of course, ESS does not have its own menuing system. Without having Portal bookmarks available, how do we allow users to navigate in the various ESS pages? One quick way to do that is by building a basic HTLM page that you can put out there with links to help your users navigate into the specific ESS pages you want to make available.

Let’s talk about Process Flow. This is one of my personal favorite topics. I’m going to be presenting specifically on IPA on Friday morning at 11:00 eastern. Please come. Of course, we’ve all heard that with moving to Lawson 10, Process Flow is replaced by Infor Process Automation. For a long time now I’ve been encouraging you to take on your PFI to IPA migration project early and separate from the Lawson 10 project. Depending on the number of flows you’ve got out there, the complexity of the flows, what the flows do, it could be a significant project and it probably involves with a lot of the same people who would otherwise be occupied working through testing or development with the Lawson 10 upgrade.

Now, we’re approaching 2016. We’re approach the end of mainstream support for Lawson 9. At this point, I think I would recommend, unless you have a really significant and complex use of Process Flow, I would recommend making that IPA migration a part of your Lawson 10 project. I would not really delay the Lawson 10 upgrade to work through a Process Flow to IPA migration first. One of those considerations is also the deployment of Landmark into the 9 environment. I’ll touch on that in a bit.

One thing I do want to mention is that Landmark runs on … Landmark is an application server. It runs your Java based Infor applications. It’s analogous to LSF, where LSF is the application server that runs COBOL based applications. Landmark is the application server that runs the next generation of Infor applications, such as global HR, strategic source, and contract management, and most importantly for us, Infor Process Automation, the next generation work flow engine. Landmark runs on AIX or Windows only at this point with Red Hat, Enterprise, Linux support imminent. Landmark does not run on I-series or the other Unix variants. If you’re running HPUX, Solaris, or the IBMI platform, you’ll definitely be looking at a heterogeneous architecture while bringing Landmark into the mix. No? Okay. Yeah.

Speaker 3: We have some participant questions. One of them is going back to Plug-ins. Could you have an LBI URL running as a custom role on your homepage in a Plug-in?

Richard: I’m not sure what you … Can you help expand on that?

Speaker 3: If you want to have a link direct to LBI in your dashboard inside of your SharePoint for …

Richard: Yeah. You could totally do that with it. You could totally do that with a deep link. If we were on our Mingle page, and we’re maybe looking at the Mingle homepage, yeah, we could put a link right on the Mingle homepage that takes you directly to the LBI Plug-in. Yeah, we could do that. You’ve got some flexibility there, I guess, is really to try and answer the question. This is definitely something you want to explore and play with once you got your first Lawson 10 environment up and running. Take some time to figure out how you can maybe reorganize the navigation and your Mingle page to make it easier for end users to get into the applications that they need to get into with a minimum number of clicks.

Speaker 3: Lance is asking, “If we’re going to extend 9.01 support for one year, would you recommend again that we upgrade to IPA ahead of that application upgrade?”

Richard: That’s a good one. I would say that depends. Let’s talk a little bit about the Java requirement. As of today, there is only one version of Landmark in mainstream support and that is Landmark 10.1.1. Landmark 10.2 should be dropping very soon, but at the moment, Landmark 10.1.1 is the only version in mainstream support. Landmark 10.1.1 runs on a Java 7 platform with Webserver 8.5. in order for triggers to work so flows in IPA can be triggered by business events in the Lawson application, you need to be running Java 7 across the board. That means your LSF server needs to be running on Java 7. Your LSF server needs to be running Webserver 8.5.

If your LSF environment is still on the Java 6 platform, if we look at what does it take to bring Landmark into my Lawson 9 environment, it involves updating my LSF server for a Java 7, updating to Webserver 8.5 and bringing in a Landmark box, federating it with LSF, all to provide the infrastructure to run IPA flows. What we found is with the Lawson 10 upgrade being a parallel upgrade approach, and taking several months to complete, when you’re looking at building out your Lawson 10 infrastructure, you do much of the same work again. There’s some effort to move the Lawson 9 environment to a place where you can install Landmark and run IPA. It becomes redundant when building out the ten environment. I guess a lot of it really depend … to answer your question … This is Lance?

Speaker 3: Yes.

Richard: To answer your question, Lance, it depends on your project timeline. If you’re anxious to get started on IPA, because you want to take advantage of the great new features available on IPA, you want to get your users used to the new web-based inbasket, maybe you want to allow approvals to your email. Maybe you have 250 flows and you know that your developers are going to be busy for a couple of months working through those flows and getting them all working over in the IPA side and those same developers maybe are going to be really busy with bringing customizations forward when you look at the Lawson 10 upgrade, with interface work when you look at Lawson 10 upgrade, and you think, “I really want to take on this project early so we can get this finished and have those same resources pivot over to the Lawson 10 upgrade.”

At that point, yeah, maybe it makes sense to build out a Landmark infrastructure in your 9 environment. If you are on Java 6, on the LFS side, you do have the option to install the previous version of Landmark 10.1.0, which is compatible with the Java 6 platform. Just know that the Landmark 10.1.0 is no longer in mainstream support from Infor, so if you do run into any bugs or issues requiring a patch to the Infor technology level, Infors might play their card of ‘you must upgrade to a supported version to resolve an issue that requires a technology patch’.

Cool. Let’s talk a little bit about IPA, not too much, but … considerations … when moving from Process Flow to IPA, of course, the one at the forefront of your mind is probably converting over all your flows. Hey, can we convert our flows from Process Flow to IPA? The answer is yes, and that actually works pretty well. There is a conversion utility that will take your Process Flows and convert them into the format that can be run by IPA. Each and every flow still needs to be touched by a developer and you’ll find that the conversation program isn’t 100% perfect. You’ll still need a developer to work through the flows that are converted and maybe make a couple of tweaks to get everything working over on the IPA side.

What about all my approver data? Let’s say I’m using user tasks and categories to store requisition approvers? All that converts over as well. There’s a utility that dumps all that as a Logan product line and brings it into the IPA product line and that works really well. In thinking about moving our approver data from the Logan product line into the IPA, one thing to keep in mind is if you have any Crystal Reports out there that use that data … maybe you have Crystal Report that shows, “Here are all my approval matrix. Here are all the approvers from various departments.” Maybe you’ve got a Crystal Report out there that shows work units in-process. “Here are all the requisitions that are currently out for approval and here’s who are waiting on it and how long they’ve been waiting.” All that uses data from the Logan product line. IPA doesn’t use Logan anymore. IPA has its own database and the structure of that database is a little bit different from Logan, so those reports will need to get reworked to use the new schema that IPA uses to store this information.

Other consideration, we definitely recommend training when moving to IPA, on a couple of fronts. One is simply Landmark server administration. Landmark as an application server is on par with LSF in terms of complexity. You definitely want to learn how to start it, how to stop it, how to troubleshoot it, where to look in the log files, how to apply updates, all that sort of thing. On the development side, IPA is such a big step forward from Process Flow. There’s so many new things. We’re taking on this project. This is a great time to get your Process Flow developers some additional training so you can get them up to speed so they can quickly take advantage of all the new functionality in IPA and probably be encouraged and inspired to go on and build new exciting automations, taking advantage of the new tools that are available.

Finally, one other consideration, moving from Process Flow to IPA is the cut over strategy. It’s more of a concern when you’re doing the IPA migration as a separate project. Of course, when moving the Lawson 10, you have a whole cut over of all of your application data, environment, technology, configuration, interfaces, user interfaces. There are so many pieces that move with Lawson 10. IPA is just one piece but when looking at doing a Process Flow to IPA migration as a separate project, some things convert over, such as the Logan data. There’s a conversion utility with Process Flow. Some things don’t convert quite so easily and that is in-process work units. If you have working units in-process, meaning items that are currently out for approval.

At the moment that you make the cut over from Process Flow to IPA, there is not a built-in ability to bring those active work units over from Process Flow to IPA. You got a couple of options. You can run both work flow engines in parallel. Run out the items in-Process Flow while some new items are going out for approval in IPA or you can use a flow or a query or three business analysts in a room to go and find that all items are currently out for approval, cancel them on the Process Flow side, and restart them on the IPA side.

Cool. Do you want to talk about ISS? All right. ISS, this is a product that has become an integral component to your LSF and Landmark environment. ISS is the piece that federates our two application servers, LSF and Landmark, because Landmark also has a security system and it also has a repository of users, classes, and roles, and we really want to keep all of that data in sync with what’s going on on the LSF side. While LSF uses a ADAP repository for security data thats either Tivoli or ADLDs, Landmark has its own separate repository of security data. It’s actually just stored in the Landmark Gen database and we use ISS to bind those two environments for Single Sign On, as well as to synchronize the security data between the two systems. What does ISS really look like? It’s basically a WebSphere application that installs on the LSF server. One advantage of having ISS available on your environment is that it provides a great web interface that you can use for user account maintenance.

Tasks that you would typically do in a Lawson Security Administrator desktop client in the Lawson 9 world, such as creating a new user, deactivating a user, changing roles assigned to a user, all that can be done within the ISS web interface. ISS also provides our federation to Landmark, so if I’m building out a Lawson 10 environment, I’m going to get LSF up and running on its own. I’m going to get Landmark up and running on its own then I’m going to install ISS on my LSF server. Once I have ISS installed and working, I’m going to go into my federation menu and federate with Landmark at which point ISS is going to communicate with the Landmark server, and at that point I can initiate a sync.

An ISS sync is going to compare all the security data on both LSF and Landmark and basically make it the same and if there are any conflicts, I’m going to have to resolve those conflicts either through ISS itself or through various other tools, such as Lawson Security Administrator, the Landmark rich client interface, and if worse comes to worst, JXplorer, if I need to clean clean up some corrupt data that I can’t sync otherwise.

With my system synchronized ISS allows me to set my primary authenticating system. We have a choice now which application server becomes the primary authenticating system across the environment. Typically, these days, we most often see LSF as the primary authenticating system. A couple of years ago, it was more common to set Landmark as the primary authenticating system. You’ve really got an option for either, today.

Let’s talk a little bit about release strategy. This isn’t really just a Lawson 10 thing. This applies to Lawson 9, now, but I think it’s pretty important to keep in mind when you’re planning your Lawson 10 project. The policy from Infor now is that technology patches are only available … New technology patches are only going to be made available for N-2 versions. What does that mean? N is the current version. If a patch needs to come out to LSF, maybe because Microsoft released the patch to Windows that impacts LSF and Infor needs to release a corresponding patch, or maybe there’s a change to a BSI tax factory, that Infor needs to put out a technology patch to accommodate a change in BSI.

The current version of LSF is 10.08. Infor will supply that technology patch for LSF 10.08, 10.07, and 10.06 and that is it. If you are on an earlier version of LSF, you’ll be forced to do an ESP to reach a level where this patch is available. This only really applies on the technology side. Applications are patched at source, so we don’t have this requirement for CTPs. It’s really just technology patches. I’ll get to you in one sec. The environment patches are now on a standard release schedule, so ESPs come out in April and October. 10.08 just dropped and application MSPs come out once a year in April. Other components in the Lawson ecosystem are coming out with patches more often. For example, Landmark CUs come out about once every month. Yeah?

Speaker 3: Richard, we have a question from Joe. He wants to know why active directory was not listed on your ISS slide.

Richard: Because ISS doesn’t talk to active directory, because ISS is not a replacment for Lawson security. ISS is a layer that runs on top of the Lawson security components, and if we look at it, how does Lawson talk to active directory? That matters for password authentication. Whenever you’re entering a user name and password into a Lawson application, it needs to go and talk to active directory and validates that that password is correct. ISS doesn’t really do that. That’s handled by the Lawson Security layer, the LASE layer over on the LSF side, as well as on the Landmark side. If you’re logging into a Landmark rich client, for example, your Landmark application server is also going to be bound then to AD and be able to independently connect to your domain controller and validate a password. Really, ISS runs at a higher level and ISS keeps those two systems in sync and sets your primary authenticating service SSOP or SSOPv2, but it leaves it down to the lower level application server, Lawson security component of the application servers, to do a AD bind. Hopefully, that makes it less confusing and not more.

Cool. Let’s get into upgrade planning, upgrade approach. What order should it go? Of course, anyone who still has some LAUA classes out there, you know that LAUA is no longer supported in Lawson 10. We definitely recommend taking on the LAUA to Lawson Security migration project in advance, because in the Lawson 9 world, you have the flexibility to move over, basically on a user by user basis, to slowly roll out Lawson Security, rather than more of a big bang approach with just cutting over to Lawson 10. Landmark and IPA, does it make sense to do that now as a separate project? Does it make sense to do it with Lawson 10? I would say your circumstances will vary. If you’ve got just a couple of flows, moderate use of process or a moderate complexity, I would argue that it probably makes sense to make that a part of your Lawson 10 upgrade, just at this point. What’s the approach to upgrading to Lawson 10?

Pretty much the two basic categories of upgrade approach are in place or parallel. An in place upgrade means taking an existing environment and applying an update to it to bring that environment up to a newer version. A parallel upgrade means installing a separate environment that runs on the side of your existing environment and then basically doing a cut over from the old environment to the new environment. Whilst technically both of these scenarios are supported for the Lawson 10 upgrade on the Unix platform, in reality, we don’t know of a successful in place upgrade that’s been done for Lawson 10. All Lawson 10 upgrades that have been done have used a parallel approach and that’s certainly the approach that we’re going to recommend in moving to Lawson 10.

Really, every project is unique. You’ve got a different configurations of Lawson, different numbers of environments, different set of models and applications deployed, and different business requirements, as far as change management and who’s involved with testings, customizations, what have you. With every approach being somewhat unique, I would like to talk through one approach that’s worked really well for us, especially if you’re a customer that runs two environments, has a PROD environment and a TEST environment. Let’s say that you’re doing a … you’re planning on your Lawson 10 upgrade, and you’ve got two environments that you run on premise, not in the cloud. One approach that you might take to doing your upgrade is what we call a three pass upgrade.

In this approach, we start by building out our new Lawson … what becomes our Lawson 10 test environment. You’ll build this out on a new virtual hardware. We start by getting Lawson 10 installed and running with all the products in your portfolio and then we want to do our first pass to populate that test environment with data and configuration. We draw from the current production environment or a recent copy of your current production environment and we want to bring in not just the product line data run the data off your programs, but we want to bring in security, we want to bring in the user’s base, we want to bring in if you have LBI, look at reports and report history, that sort of thing. We also want to bring over all of our customizations and interfaces, and then this 10 test environment becomes a development environment that we use to work on getting our customizations tested and working with Lawson 10, especially if you’ve got, say, ESS customizations and you’re updating a newer version of ESS, those customizations need to get reapplied. We use this environment as our development environment for that effort.

Next we move on to building our future live environment, so we take all the lessons learned that we have from creating a test environment. We look at the final set of patches that we’re deployed with, all the configuration decisions that were made, and we roll that into our Lawson 10 build, so we look at building a pristine … a future live environment, then we need to populate that with data, the user’s configuration, and that becomes our second pass. Again, we draw from Lawson 9 PROD or a recent copy of the PROD environment to populate our Lawson 10 environment with data, with users, with configuration. This time, since we’ve already done it once, we’re looking at validating that our go live approach is complete. We look at collecting timings. Each step along the way, in the upgrade pass, we track what was the start time, what was the end time, and we use that to predict what’s going to be our downtime window for actual go-live event.

With our data brought over from Lawson 9, we still need to get our customizations in, and for that, we’re going to promote our customizations that we’ve already tested and developed and tested in our 10 TEST environment. We’ll promote that code to our 10 prod, keeping a pristine PROD environment and that includes a promotion of flows in IPA as well. If you’re doing a Process Flow migration and doing all that development on the test side, then you’re promoting clean code in your pre-live environment.

Our final pass, our third pass, is our go-live, at which point, we are getting our final application data migration and then of course cutting over interfaces for a successful Lawson 10 live. I’ve talked about doing TEST first approach. Some organizations prefer to do a PROD first approach, where all of your project activity is going into the PROD server. There are pros and cons. We’ve done it both ways. I happen to like this scenario because it leaves you with a cleaner or more pristine PROD environment build, but there are some advantages to doing a PROD first scenario as well, such as you’re putting that PROD environment through more activity, through the life of the product. You have more opportunity to test the actual pre-live hardware. You get a better feel for performance of that machine and you get to test from the actual patch set that you’re going to go live with, throughout the duration of the project, rather than just doing it through all the patches and then a final UAT before live.

Speaker 4: Why would you do more than three passes for a project?

Richard: Why would you do more than three passes? That’s a great question. Depending on the complexity of your upgrade pass, you might decide that three isn’t enough. Three’s pretty much the minimum you want to do. Pass one, that establishes the baseline. That’s where we really figure out what are all the pieces that make up this upgrade pass? How is this going to work? Two is your trial, your trial go live, your dry run and go-live and then three is your live, but you might want to get some more passes in there, for a couple of reasons. One will be timeline. Let’s say you’ve got a lot of custom code. Maybe you’re doing a platform migration and you need to do … you’ve got a lot of scripts that you need to get converted over to the new platform. Maybe you are converting an I-series to Windows and you’ve got RPG code that needs to get rewritten in 4GL.

If your timeline stretches on, beyond six months, the data in your 10 environment starts to get stale, and it’s going to be a lot easier to do testing with a fresher set of data. Maybe you want to do a parallel payroll run as part of your upgrade project, in which case, you want to make sure that your 10 environment and your 9 test environment get refreshed at exactly the same moment at the point that you’re ready to do a payroll run and can compare the results in both systems. Maybe your upgrade pass has so many moving parts to it. Maybe you’re doing a database conversion as part of your upgrade and you really just want to be sure that you practiced this enough. Maybe your second pass, maybe you weren’t happy with the timings in the second pass. Maybe you looked at that and you said, “According to the data we collected from our second pass, it’s going to take 72 hours to go live, and that’ not acceptable from a business standpoint.”

We want to look at optimizing some of those process. We want to look at, “Do we need to do a data archive first? Do we need to archive some data out of our Lawson 9 environment to reduce the amount of data that’s running through the upgrade programs? We want to look at anything for upgrade capacity, what pieces can we load in advance of go-live?”

For example, security is one that we often do. Just a couple of day before go-live, we’ll often do our final security migration and that leaves us with the Thursday and Friday of dual maintaining security or having a security freeze right before go-live and that reduces the number of things we need to do over that go-live weekend. Cool. I’ve got up here so many components might make up what we call an upgrade pass. Of course application data is the most important. It’s the one that you’re mainly thinking of but there’s so many other pieces that we want to track. With our upgrade projects we put together a tracking document that basically lists off all the components that make up an upgrade pass and then we track whether or not each of these components is going to be present in each of our upgrade passes we do, the first, second, third, possibly a fourth, when we’re going to do that, and the live event is something that’s done in the days leading up to go-live versus part of our go-live activity.

Other things to keep in mind beyond the application data is of course security. You’ve got your environment data GEN, LOGAN. That’s things like jobs. If you’ve got jobs, recurring jobs, scheduled jobs, all that stuff needs to come over. Of course, like with any applications update, anytime you do an MSP, that’s generally going to force you to recreate a lot of your saved jobs. If you’ve got print files that you want to copy over … If you’re doing a Unix to Windows migration, this is going to be impacted by the change to an NT ID that are tracked for user names. If you’ve got LBI, you’re looking at bringing over your Crystal Reports, but you also might want to bring over your report history, your saved instances of those reports. Of course, your work flow information. It’s not very common to bring over work unit history but you definitely want to bring over IPA. Make sure your IPA’s configured, that it has the same or a relevant set of configuration for the 10 environment and all your flows are set up and working.

I’ll touch on a couple of things that make an upgrade product unique. When that upgrade project is also a platform migration. For us, the projects that we’ve done platform migrations, most commonly Unix to Windows. Also we’ve done I-series to Windows. If you’re looking at moving to the cloud, of course, we’ve done several upgrade X projects, and if you’re not currently running Lawson on the Windows environment for your on-premise deployment, platform migration becomes a part of your upgrade X project, because the cloud is based on Microsoft technologies.

Looking at what’s unique in a platform migration, of course, the biggest aspect of that is probably the database conversion. If you’re going from Oracle to SQL. Over on the environment side, look at scripts that you have, any custom programs that you, any programs that you have running on the Lawson server that need to get converted to work on that new platform. Interfaces, as well, anything that touches the database layer.

Speaker 4: Reports.

Richard: Reports. Reports is a big one. Even like Access databases that may be out there in the field that we don’t necessarily track or know about, essentially, in IT, because the users have had database access for so many years. All of that gets impacted as we’re moving to a new platform. I want to talk a little bit about the upgrade programs and how they work. With Lawson 10, Infor rewrote the way that the upgrade programs work. Previously, if you think about when you went from 9.00 to 9.01, the upgrade programs were pretty much COBOL based applications and they would work by reading out each record from your 9.00 product line and building that record into the 9.01 product line, possibly doing some schema changes along the way.

That method was really slow and a lot of organizations found that the Lawson upgrade programs took days and days and days to run beyond the acceptable downtime window. To mitigate that, Infor has reworked the way that the upgrade programs operate and they’re a lot more efficient now, because they can actually use direct SQL queries against the database to get the data moved over much faster than running each record through the COBOL layer.

This direct SQL changes. This happens through a process called SQL DB copy. Your upgrade programs will use SQL DB copy, as long as you’ve got all your JVC settings set up correctly and as long as your source and target product lines are on the same database platform, same database server. You don’t have that available if you’re doing a platform migration. If your source product line is hosted in an Oracle database and your target product line is posted in a SQL Server database, at that point you have to use DB copy rather and SQL DB copy, which is basically a slower method to move the data over. You’ve got that option available to you.

Another option available is to go outside the Infor tool set to do a separate database migration. That’s a process that’s worked well for us, in the past. Rather than using the Infor tool set to move databases, we’ll use, for example, SQL Server Migration Assistant to get data moved over from Oracle to SQL. Once we’ve got everything housed in the same database server, that allows us to take advantage of the SQL DB copy upgrade programs which runs so much faster.

Cool. Wrapping it up here only five minutes late, which is excellent time for me. Do want to emphasize testing more than ever with this upgrade compared to past upgrades. Look at things you might not have looked at in the past like browser compatibility is a big one. Lawson 10. Basically with Internet Explorer, all Lawson 10 apps are going to run on the standards mode. That is the oppose of Lawson 9, which ran in compatibility mode. You do want to take special care of making sure that the desktop environments that are out in your organization run Lawson 10 without issue and they run Lawson 10 fast. Probably no one has Windows XP out in the field anymore. If you do, you’ll find it’s really not compatible with Lawson 10. Even the Lawson 10 web interface is not really capable of running on XP machines anymore.

Finally, I’ll wrap it up with training. What’s the training that we are most often asked to provide as part of our Lawson upgrade projects? On the application side, there’s not a ton of differences between the 9.01 apps and the 10 apps. We do some differences training. A lot of that, we’re actually highlighting this week as part of our webinar series. Most of the training needs to happen on the technical side, especially if you’re adding Landmark in the mix. You need to learn how to administer the Landmark system. If you’re moving from Process Flow to IPA, you really want to learn how to take advantage of all those new features in IPA. You also want to learn how to administer flow son the IPA side. If you think of a materials director who is used to maintaining the user’s task and categories in the BPM admin screen, that interface changes for IPAs.

The first thing is he needs to get up to speed with how to do that task on the IPA side. Security is another big one, if you’re implementing ISS. Don’t forget your user provisioning team. If you have a separate group, maybe an IT help desk that creates user accounts for all your Enterprise applications, they need to get onboard with the new method for maintaining users in Lawson 10.

Finally, we’re adding some Windows components in the mix, so if your Lawson environment has been purely Unix or purely series-I in the past, you do want to make sure you have a little bit of Windows skill set available to you and having a little bit of SharePoint knowledge certainly helps, although it’s not required to be a SharePoint expert, because it’s set up and running, there’s no day to day maintenance for SharePoint in Lawson 10.

Speaker 4: Still have time for question?

Richard: We still have time for questions. Thank you so much, everyone, for attending what will probably be my final rendition of the Lawson 10 technical differences. We need to do something new for 2016. I promise you new and exciting Lawson 10 content in 2016. The rest of this week, we have so much cool stuff going on. Later today, Jeff House, ESS outside the firewall, talking about new features projects we just did, very exciting. That’s at 1:00. A special guest from Hershey Medicals Center, Jerry Stolfas is here to talk about Landmark admin for LSF administrators.

Speaker 4: A very popular presentation …

Richard: Very popular.

Speaker 4: … at the NW login in the keystone.

Richard: That’s at 3:00 eastern?

Speaker 4: That’s at 2:00pm eastern.

Richard: 2:00pm eastern. Finally, wrapping up today, at 4:00pm eastern, we have our Landmark panel. First time we’re doing this as a live webinar. We have half a dozen consultants with no safety net. That’s right. No PowerPoint. It’s just Q&A. Stump the consultants. That’s going to be really run today, 4:00pm eastern. What do we have on tap the rest of the week?

Speaker 4: Tomorrow we have five HR presentations starting with ACA. We’re going to talk about GHR. We’re going to talk about S3 10x differences. We’re going to talk about S3 to GHR differences. On Friday, we have a couple of very exciting presentations. We have a latest rendition of IPA, which has proved very popular. This is a great presentation, not just for technical but general audience. We’re also going to do our financial 10x differences, not to be left behind. We’re going to debut our 10 favorite things about 10x, which I’m very excited about.

Richard: Get into the holiday spirit for a few of my favorite things for Lawson 10x. That’s Friday after 10:00.

Speaker 4: Thank you, everyone, for joining us.

Richard: Thank you.