Smart Office is installed via ClickOnce. The link that you click on to launch Smart Office can have a number of paramaters on the URL. In this post I will cover a few of those parameters and the most common misstakes people do when composing a URL that will open a program after Smart Office is started.
Lawson Smart Office always needs a server to start and execute. The client receives this information, a URL to the Lawson Grid over HTTPS, as a start parameter, or else retrieves it as from a group policy set in Active Directory. The URL to the Lawson Grid is stored in a local file and if Lawson Smart Office is started from the Windows Start menu, the URL will be taken from the local file (if there is not a group policy that prohibits this). It is also possible to install Smart Office via a MSI installation and in that case the start URL will not work nor the examples provided in this post.
Even though the installation point is connected to a specific server for Lawson Smart Office, Lawson Smart Office can be reconfigured to connect to any other Server for Lawson Smart Office as long as the server is of a supported version. This makes it possible to have one installation point that serves as a production environment and a test environment at the same time.
If you are interested in using a msi installation you should read Lawson Smart Office and desktop virtualized environments.
To specify a new server URL to Lawson Smart Office, start the client with a URL that is composed this way:
http://installpoint/LawsonClient.application?server=https://gridserverurl Example: http://myserver/LSO/Lawson.Client.application?server=https://myserver.mycorp.com:19006
Every time Lawson Smart Office is started with a URL, the installation point must be accessible. When starting Lawson Smart Office from the Start menu in Windows, it is not necessary for the installation point to be accessible; Lawson Smart Office will start anyway.
server – The URL to the Smart Office Server
task – Pass in a task that should be launched on startup for example internal://log
profile – The namn of the profile that Smart Office should start with.
file – The path to a file that should be launched at startup. The file could contain a widget, a set of tasks or a canvas.
language – The language to start the client with. Default is the language on the client PC, but if that isn’t the default that you want you should use this parameter. Note that it does not apply if the user has already run Smart Office so this is used for new installs. Use sv for Swedish or en-US for English.
languageoverride – This will override the selected language as well if the user is using Smart Office in another language.
updatefeatures – This will delete all local downloaded features and download them again from the server. This flag might be useful if you are using the SDK and have forgotten to update the version of a feature as you deploy it. It should only be used for testing as this is not a disired behavior.
Task is probably the mosted used parameter (except for server). It will allow you to send in a task that should be launched. The task is a URL since anything you launch in Smart Office has the form of an URL and that URL can contain parameters as well. You can for example start DAF with a document(s) directly from your email or other program that can launch links:
This brings me to a key point and the source of a lot of frustration. All parameters in a query string have to be URL encoded. Okey it will work in a lot of cases becuase the implementation is forgiving but when you have issues with an URL the issue is almost always that the URL isn’t valid.
URL encode parameters
Any parameter that can contain a character that is not valid in a URL has to be encoded. When you have a URL that takes a parameter that is a URL that has parameters this means that you might have to encode parameters more than once.
When I get a question with a URL that isn’t working as expected I quickly look for two things, it there a space in the URL, like in the name of the profile?
A space should be encoded to %20.
Is there more than one ‘?’ in the URL? Than there is probably another set of parameters and it will make it hard to know if a parameter belongs to the first URL or the second.
Say that the QK_xquery might contain a space, and then you should first encode that parameter. Since the task itself is a parameter that should be encoded as well. Now in many cases you don’t need that kind of double encoding it depends, so you can always try the URL first, but if it doesn’t work or if you are genereting it in code – you should always encode the parameters.
There are a bunch of online URL encoders /decoders that you can use. For example this one.
Url Encoder Utility
I have created a tool that allows you to verify how a URL will be split into parameters and it also allows you to select the part of the URL that should be encoded so that you can encode it in multiple steps.
The Document Achive above will look like this encoded:
The tool also supports XML encoding if you want to encode a value that is to be placed in an XML element node.
The encoded URL is harder to read, I know. But to always encode is the only way to assure that it will always work if the parameters are dynamic.
Download UrlEncoderUtility.zip from my SkyDrive. Unzip the content and run the exe to run the program.