Daniel Nashed 13 November 2009 10:35:53
Last week I was looking for some good examples to demo for a customer. When I opened a new PMR I noticed that with the new system there is an URL which contains the PMR number.
The PMR example turned out to be quite complex and a good example. Implementing a lookup for SPRs, TNs in fixlist and Kbase was the logical next step and more easy afterwards.
I am now using those lookups for a week and it is quite convenient.
This blog post is a quick introduction how to use LiveText and own recognizers in the Notes 8.x standard client.
It is not a complete introduction into LiveText and does not start at intro level. This blog post is only to explain details of the text recognizers and how to map parameters and demo the PMR example.
You first have to enable Widgets and LiveText in general and have to be familiar with Widgets in general.
A PMR number consists of 3 parts Number, Branch and CountryCode
If you look into an example PMR you see the 3 parts. Sometimes there is a "#" between PMR, sometimes it is separated by comma, sometimes with blanks.
But in general the format is very similar and looks like this.
PMR # 66129 SGC 724
The new IBM SR tool allows URLs like this which contain those three parts and allows a direct jump into the PMR.
https://www.ibm.com/support/servicerequest/problemDescriptionSelect.action?userType=0&sourceAppl=XSR&srNumber=
66129&branch=
SGC&retainCountryCode=
724
What we need to implement the Widgets are the following components.
- a Recognizer for parsing the PMR number format
- a Content Type the Recognizer can feed
- a Widget invoking the URL passing the parameters defined in the new Content Type
- a New Action which binds Content Type and Widget together
Let's start with the recognizer. First of all we need a name for the recognizer and a regular expression matching the PMR number.
I tried to match all formats got thru the SR system per mail and what normally used when typing a PMR.
It always starts wth PMR can have a ":" or "#" or just a blank in between. Has a 5 digit number. Than a 3 digit alpha/number string and a 3 digit number.
Can be separated by comma or blank and there might be more blanks in between.
The Recognizer uses regular expressions which are a lot of fun and are around in Unix for a long time.
Here is the current regular expression I am using to parse a PMR number.
\bPMR[#: ]*?([0-9]{5})[ ,]*?([A-Z0-9]{3})[ ,]*?([0-9]{3})\b
The important part in this regular expression is that parts of the string which should be used as separated parameters are put together in round brackets.
I marked the three parameters in the same colors I used for my sample PMR above.
Once you have defined those three parameters the next step is to map them to a content type.
Because there is no build-in content type for PMR numbers you have to create a new one (see below) with the three parameters and name them accordingly.
After creating the content type you can start mapping the parameters.
The Grouping Number is used to specify the parameter. Grouping number 0 stands for the complete text that matched the regular expression.
Group Number 1 stands for the expression in the first round bracket (red).
Group Number 2 stands for the next bracket and so on ...
You can simply add more Content Properties and map them with the corresponding grouping.
When this is done you have defined a new recognizer and mapped it to a content type.
The next step is to create a Widget which can consume our new content type.
Configuration of new Recognizer
Configuration of new Content Type
Now we can build our Widget by invoking the Widget Wizzard. You select a WebSite Widget and just paste in the URL above.
It would make sense to replace the PMR number with one of your active PMR numbers because the Wizard connects to the website and asks for authentication.
The authentication is cached and you only have to enter it when the session expires.
I tried to get the automated authentication working but I did not get the IBM login form working.
I was able to set the username and password but the page was not submitted. Did anyone get it working with the IBM account?
Because the parameters are passed via URL the request type is a HTTP GET.
In the next step you might want to change the name of the Widget.
The wire action is defined in a later step.
Passing multiple parameters for the PMR can be configured in the Advanced tab.
In this example all parameters are required but not all of them will be filled using the PMR recognizer.
Therefore they are set to required and have a default value.
The other Parameters will be mapped using the wire option when configuring a LiveText action.
Those names will match the corresponding names from the PMR Content Type.
After finalizing the Widget (I left out some of the screens) we have defined the PMR Widget.
The only missing part is the LiveText Wire between the Recognizer, Content-Type and the Widget.
When configuring the new action for the Widget (right click on the Widget) you have to select the right Content Type and choose the right parameters using the Advanced tab.
Because of the three parameters we need the advanced tab.
This was the last step to wire all the components together.
Now you should be able to recognize content in incoming mail and other documents.
Below is an example of what types of PMR formats are automatically recognized with this regular expression.
If you have other formats that do not work yet let me know and I will update the regular expression if possible.
You see also the other LiveText I build for TNs and SPRs. The actions I am currently using is a FT search in Kbase and Fixlist database.
I am still playing around with Widgets my first look into this... I hope you find my example helpful.
-- Daniel
![[IBM Lotus Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}