• This has been posted earlier on lab.klemespen.com.
• Even though some of these ideas are not what you’d normally implement in a business environment, some of the concepts can obviously be transferred over to businesses trying to provide an efficient workplace for its employees.
• Norch is developed by Fergus McDowall, an employee of Comerio.

What if you could index your whole life and make this lifeindex available through search? What would that look like, and how could it help you? Refinding information is obviously one of the use case for this type of search. I’m guessing there’s a lot more, and I’m curious to figure them out.

Actions and reactions instead of web pages

I had the lifeindex idea for a little while now. Originally the idea was to index everything I browsed. From what I know and where Norch is, it would take a while before I was anywhere close to achieving that goal. Then I thought of IFTTT, and saw it as a ‘next best thing’. But then it hit me that now I’m indexing actions, and that’s way better than pages. But what I’m missing from most sources now are the reactions to my actions. If I have a question, I also want to crawl and index the answer. If I have a statement, I want to get the critique indexed.

IFTTT and similar services (like Zapier) is quite limiting in their choice of triggers. Not sure if this is because of choices done by those services or limitations from the sites they crawl/pull information from.

A quick fix for this, and a generally good idea for Search Engines, would be to switch from a preview of your content to the actual content in the form of an embed-view. Here exemplified:

Will embed-view of your content replace the preview-pane in modern #search #engine solutions? Why preview when you can have the real deal?

— Espen Klem (@eklem) November 24, 2014

Technology: Hello IFTTT, Google SpreadSheet and Norch

IFTTT is triggered by my actions, and stores some data to a series of spreadsheets on Google Drive. These spreadsheets can deliver JSON. After a little document processing these JSON-files can be fed to the Norch-indexer.

Why hasn’t this idea popped up earlier?

Search engines used to be hardware guzzling technology. With Norch, the “NOde seaRCH” engine, that has changed. Elasticsearch and Solr are easy and small compared to i.e. SharePoint Search, but still it needs a lot of hardware. Norch can run on a Raspberry Pi, and soon it will be able to run in your browser. Maybe data sets closer to small data is more interesting than big data?

Norch running on a Raspberry Pi

Why using a search engine?

It’s cheap and quick. I’m not a developer, and I’ll still be able to glue all these sources together. Search engines are often a good choice when you have multiple sources. IFTTT and Google SpreadSheet makes it even easier, normalising the input and delivering it as JSON.

How far in the process have I come?

So far, I’ve set up a lot of triggers/sources at IFTTT.com:

• Instagram: When posting or liking both photos and videos.
• Flickr: When posting an image, creating a set or linking a photo.
• Google Calendar: When adding something to one of my calendars.
• Facebook: When i post a link, is tagged, post a status message.
• Twitter: When I tweet, retweet, reply or if somebody mentions me.
• Youtube: When I post or like a video.
• GitHub: When I create an issue, gets assigned to an issue or any issues that I part take in is closed.
• WordPress: When new posts or comments on posts.
• Android location tracking: When I enter and exit certain areas.
• Android phone log: Placed, received and missed calls.
• Gmail: Starred emails.

And gotten a good chunk of data. Indexing my SMS’es felt a bit creepy, so I stopped doing that. And storing email just sounded too excessive, but I think starred emails would suit the purpose of the project.

Those Google Drive documents are giving me JSON. Not JSON that I can feed directly Norch-indexer, it needs a little trimming.

Issues discovered so far

Manual work

This search solution needs a lot of manual setup. Every trigger needs to be set up manually. Everytime a new trigger is triggered, I get a new spreadsheet that needs a title row added. Or else, the JSON variables will look funny, since first row is used for variable names.

The spreadsheets only accepts 2000 rows. After that a new file is created. Either I need to delete content, rename the file or reconfigure some stuff.

Level of maturity

IFTTT is a really nice service, and they treat their users well. But, for now, it’s not something you can trust fully.

Cleaning up duplicates and obsolete stuff

I have no way of removing stuff from the index automatically at this point. If I delete something I’ve added/written/created, it will not be reflected in the index.

Missing sources

Books I buy, music I listen to, movies and TV-series I watch. Or Amazon, Spotify, Netflix and HBO. Apart from that, there are no Norwegian services available through IFTTT.

History

The crawling is triggered by my actions. That leaves me without history. So, i.e. new contacts on LinkedIn is meaningless when I don’t get to index the existing ones.

Next steps

JSON clean-up

I need to make a document processing step. Norch-document-processor would be nice if it had handled JSON in addition to HTML. Not yet, but maybe in the future? Anyway, there’s just a small amount of JSON clean-up before I got my data in and index.

When this step is done, a first version can be demoed.

UX and front-end code

To show the full potential, I need some interaction design of the idea. For now they’re all in my head. And these sketches needs to be converted to HTML, CSS and Angular view.

Embed codes

Figure out how to embed Instagram, Flickr, Facebook and LinkedIn-posts, Google Maps, federated phonebook search etc.

OAUTH configuration

Set up OAUTH NPM package to access non-public spreadsheets on Google Drive. Then I can add some of the less open information I have stored.

Noen utvalgte bilder fra arrangementet:

Ole-Kristian Villabø ønsker velkommen.

Ole-Kristian Villabø om Comperio sine 10 år

Per Ejnar Thomsen fra TINE om deres virksomhetssøk.

Kjell Skognes om SINTEFs søkeløsning SIPOK

Fagleder Hans Terje Bakke om blant annet Elasticsearch og Kibana.

Elasticsearch is an open source search and analytics engine that extends the limits of full-text search through a robust set of APIs and DSLs, to deliver a flexible and almost limitless search experience.

L is for Logstash

One of the most popular open source log parser solutions on the market, Logstash has the possibility of reading any data source and extracting the data in JSON format, easy to use and running in minutes.

K is for Kibana

A data visualization engine, Kibana allows the user to create custom dashboards and to analyze Elasticsearch data on-the-fly and in real-time.

Getting set up

To start using this technology, you just need to install the three above mentioned components, which actually means downloading and unzipping three archive files.

The data flow is this: the log files are text files residing in a folder. Logstash will use a configuration file to read from the logs and parse all the entries. The parsed data will be sent to Elasticsearch for storing. Once here, it can be easily read and displayed by Kibana.

Parsing SharePoint ULS log files with Logstash

We will now focus on the most simple and straightforward way of getting this to work, without any additional configuration or settings. Our goal is to open Kibana and be able to configure some charts that will help us visualize and explore what type of entries we have in the SharePoint ULS logs, and to be able to search the logs for interesting entries.

To begin, we need some ULS log files from SharePoint that will be placed in a folder on the server (I am working on a Windows Server virtual environment) where we are testing the ELK stack. My ULS logs are located here: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

As an example, the first line in one of my log files looks like this:

05/06/2014 10:20:20.85 wsstracing.exe (0x0900)                 0x0928SharePoint Foundation         Tracing Controller Service    5152InformationTracing Service started.

The next step is to build the configuration file. This is a text file with a .config extension, located by default in the Logstash folder. The starting point for the content of this file would be: 

input {  
 file {  
  type => "sharepointlog" 
    path => ["[folder where the logs reside]/*.log"] 
   start_position => "beginning" 
   codec => "plain" 
} 
} 
filter  
{ 
 } 
output  
{    
 elasticsearch {  
embedded => true 
 } 
}

The Input defines the location of the logs and some reading parameters, like the starting position where Logstash will begin parsing the files. The Output section defines the location of the parsed data, in our case the Elasticsearch instance installed on the same server.

Now for the important part, the Filter section. The Filter section contains one or more GROK patterns that are used by Logstash for identifying the format of the log entries. There are many types of entries, but we are focusing on the event type and message, so we have to parse all the parameters up to the message part in order to get what we need.

The documentation is pretty detailed when it comes to GROK and a pattern debugger website with a GROK testing engine is available online, so you can develop and test your patterns before actually running them in Logstash.

So this is what I came up with for the SharePoint ULS logs:

filter { 
   if [type] == "sharepointlog" { 
grok { 
match => [ "message",  
"(?<parsedtime>%{MONTHNUM}/%{MONTHDAY}/%{YEAR} %{HOUR}:%{MINUTE}:%{SECOND}) \t%{DATA:process} \(%{DATA:processcode}\)(\s*)\t%{DATA:tid}(\s*)\t(?<area>.*)(\s*)\t(?<category>.*)(\s*)\t%{WORD:eventID}(\s*)\t%{WORD:level}(\s*)\t%{DATA:eventmessage}\t%{UUID:CorrelationID}"] 
match => [ "message",  
"(?<parsedtime>%{MONTHNUM}/%{MONTHDAY}/%{YEAR} %{HOUR}:%{MINUTE}:%{SECOND}) \t%{DATA:process} \(%{DATA:processcode}\)(\s*)\t%{DATA:tid}(\s*)\t(?<area>.*)(\s*)\t(?<category>.*)(\s*)\t%{WORD:eventID}(\s*)\t%{WORD:level}(\s*)\t%{DATA:eventmessage}"] 
match => [ "message",  
“(?<parsedtime>%{MONTHNUM}/%{MONTHDAY}/%{YEAR} %{HOUR}:%{MINUTE}:%{SECOND})%{GREEDYDATA}\t%{DATA:process} \(%{DATA:processcode}\)(\s*)\t%{DATA:tid}(\s*)\t(?<area>.*)(\s*)\t(?<category>.*)(\s*)\t%{WORD:eventID}(\s*)\t%{WORD:level}(\s*)\t%{DATA:eventmessage}"] 
} 
date { 
match => ["parsedtime","MM/dd/YYYY HH:mm:ss.SSS"] 
} 
   } 
}

Logstash in action

All that’s left to do is to get Logstash going and see what comes out. Run the following on the command line:

logstash.bat agent -f "sharepoint.conf"

This runs logstash as an agent, so it will monitor the file or the folder you specify in the input section of the config for changes. If you are indexing a folder where files appear periodically, you don’t need to worry about restarting the process, it will continue on its own.

Kibana time

Now let’s create a new dashboard in Kibana and see what was indexed. The most straight-forward panel type is Histogram. Make no changes to the default settings of this panel (Chart value = count, Time field = @timestamp) and you should see something similar to this:

To get some more relevant information, we can add some pie charts and let them display other properties that we have mapped, for example ‘process’ or ‘area’.  

Now let’s turn this up a notch: through Kibana we can take a look at the errors in the SharePoint logs. Create a pie chart that displays the “level” field. By clicking on the “Unexpected” slice in this chart you will filter all the dashboard on this value.  

Kibana will automatically refresh the page, the filter itself will be displayed in the “Filter” row and all you will see are the “Unexpected” events.  Time to turn to the help of a Table chart: by displaying the columns you select on the Fields section of this chart, you can view and sort the log entries for a more detailed analysis of the unexpected events.

As the Logstash process runs as an agent, you can monitor the SharePoint events in real-time! So there you have it, SharePoint log analysis using ELK.

The display templates are located in the site collection root site, under the _catalogs/Display Templates folder. Each template has two files: the html file and a javascript file. The javascript file is the one that SharePoint uses, while the html exists in order to make it easier for us developers to create and customize the display templates. Once an html file has been modified, SharePoint generates the corresponding updated javascript file, so the process is fully automated.

So what are the steps involved in creating a new display template?

In SharePoint designer, after opening the root website, navigate to the Display Templates folder. Here, in the Search subfolder, you will find the display templates that SharePoint uses for many types of results – documents, web sites, people and others. Choose a display template as a starting point for your own, depending on the result type that you are targeting, copy it and then rename it. Once saved, you will see that SharePoint has already generated the corresponding javascript file. Modify the html file as you wish. What is left to do now is to link the template to an actual result type, so that SharePoint knows what to associate your display template to. This can be done through the interface, by navigating to Site Settings – Search Result Types.

Let’s take it step by step.

Duplicating an existing display template

Open the site collection with SharePoint designer. Navigate to the Display Templates folder under _catalogs\masterpage\display templates. Here you will find some Folders that SharePoint uses to group Display Templates together.

The Word item template is in the Search folder. Make a copy of the Item_Word.html and rename it to ComperioItem_Word.html

Edit the file and inside you will see some html and javascript code.

Edit the title field so that your custom template has a different display name than the original one.

The <mso:CustomDocumentProperties> tag contains some properties of the template. Some important properties are:

• TargetControlType – tells SharePoint what the template is used for (search results, web parts, filters)
• ManagedPropertyMapping – contains a list of the managed properties that are or can be used by the current template

The <body> tag contains the rendering logic for the display template.

The template can only recognize the managed properties that are listed in the header. To use another managed property, add it here. We are using the Created property that displays the document created date.

<mso:ManagedPropertyMapping msdt:dt="string"> 
'Title':'Title','Path':'Path', [………..] , ‘Created’:’Created’ 
</mso:ManagedPropertyMapping>

Now that the template is aware of the property, you can use it by adding it to the body. Add the line below in the Body of the rendering template:

<div class="ms-descriptiontext"> _#= ctx.CurrentItem.Created =#_ </div>

Mapping the display template to a result type

Now we are going to manually link the display template to a result type, so that we can see that it works.

In order for SharePoint to use your custom template, it needs to know of it. So navigate to Site Actions – Site Settings and under Site Collection Administration choose Search Result Types. Create a New Result Type for your template like below:

• Choose a Name
• Choose Microsoft Word as content to match
• Choose your custom display template

Now go to the results page and search for a word document. The results should display a date looking like this:

We have only been scratching the surface and a lot more customization can be done here, for example formatting the date value in javascript by using a function like format(“yyyy-MM-dd”) on a Date object. Combined, SharePoint and javascript have (almost) endless possibilities.

Happy coding!

Instant search is widely known as «the way Google do it» – in fact they were the ones who started this trend and now everyone are used to it. What if you could give your SharePoint users the same experience they are already familiar with?

To begin with you must have in mind that instant search will produce a lot more queries and that your search performance will get worse if you have too many users hammering your SSA (Search Service Application). So, yes – there is a risk. The trade-off is high if you can increase the search experience to your users, but there’s also a risk of damaging the search experience totally if things start to go slow and people end up getting zero-hits.

Anyways, for the proof of concept you don’t need to think about this now :-)

Before moving on please check that you can meet these prerequisites:

Prerequisites

• Administrator Access to a SharePoint 2013 site
• SharePoint Designer 2013 or a way of mapping your site’s directory
• A text editor such as Sublime Text or Notepad++ (doesn’t really matter, but I recommend an editor with some code highlighting / intellisense)
• Basic understanding of the concept regarding DisplayTemplate in SharePoint 2013 (You can read more about it here and here :-) )

What we are going to do is that we are simply going to create a new DisplayTemplate for the SearchBox Control based on the original DisplayTemplate and edit the OnKeyUpEvent.

Changing the DisplayTemplate

1. Open SharePoint Designer 2013 and open your site
2. Browse to http://SPSite/_catalogs/masterpage/Display Template/Search
3. Create a copy of the DisplayTemplate named Control_SearchBox.html and name it Control_InstantSearchBox.html and open it and edit the <title>-tag to something else (you’ll need it do identify the template later)
4.  Go to the javascript section in the template and create a function called  doInstantSearch(clientControl, value, event) that only executes the normal query request.

It should look something like this:

1. Edit the searchbox-control’s ‘onkeyup’-event by replacing the attribute’s value with: ‘doInstantSearch($getClientControl(this), this.value, event);’ and save your template. Now you can go to your SearchBox web part and change the template to your new one (look for the title you set in step 3.) and test it yourself.
2. Now you have a one-to-one relationship between each key you press and query that you send to your SSA. However, as you will probably notice, the whole thing feels a little bit slow and not so smooth. This is because you are hammering your SSA and re-rendering your template each time you press a key – even if it’s not a real character – not so funny right? Let’s fix it.
3. In order to fix this we need to add a character-filter and a timeout to our function. We will get the character from the keyCode and try to match the character using a regular expression. In this example we will operate with a RegEx matching all alphanumeric-characters including special norwegian characters like «æ ø å». If the character matches it we will reset the timeout function and start over with a new 300 ms delay. When we hit a non-alphanumeric character or the delay times out we will execute the search request.

This is what we end up with:

And now you have an instant search with a 300 ms delay for each legal character that the user enters in the search box.

Try it yourself :)

The release of SharePoint 2013 is touted by Microsoft as a bridge from the past to the future; a pivotal shift from server- and wave-based releases to a rapid release cycle, combining the muscles from the cloud, fresh design principles and Enterprise Social technology. They’re proud, and they should be.

In the keynote, Microsoft also revealed some of the rationale behind the recent acquisition of Yammer, seeing how it complements SharePoint’s strong document-management skills with Yammer’s deep expertise in making the enterprise more social.

Jeff Teper, another high-profile SharePoint executive, told the crowds that over the last three years, Microsoft’s engineering team has centralized their effort around three important pillars: Experiences, Innovation and Ecosystem. This shows off in a dramatically improved user experience, better development tools and a completely revamped application model paving the way for us partner companies to more rapidly and with more flexibility deploy innovative applications in the cloud.

Another consistent theme throughout the keynote, was how Search now has a bigger role across SharePoint and throughout the Microsoft stack. FAST is now fully integrated, and the new search core drives both content and recommendations throughout the suite.

We now have a much better baseline when implementing Search technology in the enterprise. Hopefully this is finally the time when custom implementations of Enterprise Search will stop ending up as just a search box, and instead unleash the potential of Your organization’s accumulated knowledge and tackle today’s overwhelming growth of information.

In this example I have simply crawled the c: drive on my virtual machine with SharePoint to generate some entries in the crawl log. 269 errors aren’t that many; you could click the link and inspect the log manually in a reasonable amount of time. Viewing the logs will let you inspect 50 documents at a time.

This gets boring really fast. Therefore we started to use the API for extracting crawl logs from SharePoint [3] programmatically. Because of the API’s deprecated status the documentation is a bit on the thin side. Luckily there are some examples in the blogosphere [1,2] that helped us along and we could soon dump the crawl logs to file and ctrl-f for our missing document. Of course, the script could find the log entry and only show you the relevant one. However with a large crawl log it can take hours to extract all the log entries. It is better to dump them all to file should you need to look for a second or third file later.

Using grep, findstr or ctrl-f for searching feels wrong when you work as a search consultant. Instead the natural instinct when something large should be searched through is to index it. One option was to index it back into SharePoint through BDC (and get a possible nasty loop with reading and creating logs) or to use the old Fast API directly, bypassing SharePoint. Both felt a little heavy duty for this one-off job, and that’s when we put ElasticSearch to play. ElasticSearch is a fairly new search engine built on Lucene, and sometimes referred to as “The new kid on the block” in the Open Source Community where there’s some friendly rivalry between the Solr and ElasticSearch camps. It is a 20MB download and is ready to index documents mere seconds after you unzip the package. To index a document you simply POST some JSON to a REST endpoint and that is it. With so many libraries offering JSON-serialization and REST calls, building the world’s simplest connector doesn’t take long. We ported the old PowerShell script to C# and added 30 lines of code. With the removal of file creation code we actually reduced the lines of code overall. The indexing specific part of the script looks like this:

All we do is populate a little DTO, serialize it and push it to ElasticSearch. The indexing takes very little time, in fact fetching the logs from SharePoint is the slowest part of the connector. Notice that the call to index the document isn’t even done asynchronously. After indexing some data and indexing the logs ElasticSearch-head[4] is the easiest way to have a look. The tab “Structured Query” lets you create queries without any prior knowledge of the query syntax. As an example, here I have queried for all failing txt files in the log. (Some parts of the screen shot was dropped to make the image fit the page).

If you have a lot of failures in your SharePoint crawl log it makes sense to start with your most common cause of error. In the API each log entry has a property called ErrorId, although StatusCode would be a more fitting name (In PowerShell it seems to be called ErrorId and in C# MessageId). So in order to get the most common cause for errors one should look at the distribution of ErrorIds. In Fast Search for SharePoint this could be done by placing the ErrorIds in a managed property and configure it with the refiner property, effortlessly producing the distribution of ErrorIds. In ElasticSearch you specify refiners, called facets, at query time. In my limited test case the distribution looks like this:

It is clear that ErrorId 0 is the most common followed by 5 and 748. What the specific ErrorIds mean is unfortunately not documented. The easiest is to query for log entries with an ErrorId and look at the error description. As mentioned ErrorId 0 means OK and 1 means deleted. All failures that happen in the Fast pipeline will be wrapped with ErrorId 11. One of the ErrorIds is simply a statement from SharePoint saying that a crawl rule was honored.
Using this as a dashboard and thinking beyond a sample crawl, you could easily envision this being a tool for checking:

• How often and when a document was crawled
• Does the crawler experience issues at certain times of the day
• What crawl rates are the crawler able to sustain in the long run
• What file suffixes are most prone to errors
• What top level folders are the most troublesome to index

The code linked below should be seen as proof of concept. You are free to download and it and it will work. Some parameters on the SharePoint API-calls can surely be set better. ElasticSearch provides a bulk-update API that should be used when indexing large datasets. If you are running ElasticSearch on a non-standard port you need to change the code. Also note the complete lack of error handling.

What about that missing file? Turns out it was there all along. The customer was searching for the filename and didn’t recognize the second hit that was displaying his document’s title, not filename. Oh well.

1: http://blogs.msdn.com/b/spses/archive/2011/06/22/exporting-sharepoint-2010-search-crawl-logs.aspx
2: http://blogs.msdn.com/b/russmax/archive/2012/01/28/sharepoint-powershell-script-series-part-5-exporting-the-crawl-log-to-a-csv-file.aspx
3: http://msdn.microsoft.com/en-us/library/ms514229.aspx
4: http://mobz.github.com/elasticsearch-head
5: http://www.elasticsearch.org

The script can be found here: Program.cs

FAST ESP was, and still is, an incredibly flexible and scalable enterprise search platform and is used by customers with sophisticated search needs and a significant requirement for updating the frequency, relevance adjustments, scalability and stability. The platform has very rich semantic and linguistic characteristics, and a wide range of connectors to the underlying systems, and connection points which can search and present relevant content adapted to the users context and device. These features generate revenue and/ or reduce costs for more than 2,600 customers worldwide that use or have used the FAST ESP platform.

FAST Search and Transfer was acquired by Microsoft in 2007. Following the acquisition, it became clear that FAST ESP will not be continuing as an independent cross-platform search engine. FAST ESP will however, exist in mainstream support until 2013 (2015 for customers with a License Grant), and extended support on all OS platforms until 2018 (2020 for License Grant customers).

During this period it is possible and safe to use and even develop new services on the FAST ESP search engine. Our team of Application Management Services (AMS) consultants have extensive experience in the FAST and FAST ESP platform – many of them formerly worked in consultancy, support or services in Fast Search and Transfer / Microsoft.

While Comperio’s AMS services can customise and sustain stable operation of customers on the FAST ESP platform, we also actively advise on search strategy, design, solution architecture and new search technology, as needs and technology evolve.

Our long-term plan with Comperio Front has been making customers less dependent on the underlying search engine, and the situation with FAST ESP shows that this has been a good strategy. For our customers with Comperio Front, we are now able to provide effective transitions to new technology platforms, as well as new corporate business models, and the search engine’s position as an information hub are preserved in Comperio Front.

When it comes to transitions to new technologies post the FAST ESP era, more choices and opportunities are opening up. For many traditional FAST ESP customers in e-commerce, catalog, classified ads and media, FAST for SharePoint is not necessarily a natural choice straight away, especially if they use anything other than Microsoft technology. Comperio has experience and dialogue with several customers on the transition to open source platforms and cloud services such as Solr, Elasticsearch, Amazon Cloud Search and also Google Custom Search – when called for.

That said, Microsoft plans to further use the advanced capabilities of FAST in their products, both in Office/SharePoint/Exchange/Office365, as well as in its search engine on the internet – Bing. Microsoft’s release of FAST Search for SharePoint 2010 is an example of this and the next generation of Microsoft products will show this more clearly. For many FAST ESP customers in the business market, it is natural to follow this path, as long as it is possible to build the solutions they want. And this is also where Comperio Front comes in, as a building block to make it possible to customize the search based solutions in SharePoint in a flexible manner.

Microsoft’s development team for search, or FAST R&D department, is based in Torggata, Oslo, and works closely with both the Bing and the Microsoft Office Division development teams.
With Comperio’s close affiliation from a geographical, historical and technical perspective, we continue to follow the FAST / Microsoft team in their development (and vice-versa) with technical and strategic dialogue constantly held.

But above anything else, we want to help our clients to great search experiences!

You can learn more about FAST ESP at http://www.comperiosearch.com/products/fast-esp/ and go to www.comperiosearch.com to see other products and services offered by Comperio.

FAST ESP var og er fremdeles en utrolig fleksibel og skalerbar enterprise search platform og blir brukt av kunder med avanserte søkebehov og ekstreme behov for oppdateringshyppighet, relevansjusteringer, skalerbarhet og stabilitet. Plattformen har meget rike semantiske og lingvistiske egenskaper, og et stort utvalg av connectorer til underliggende systemer, samt tilkoblingspunkter for å kunne søke og presentere relevant innhold tilpasset brukerens kontekst og device. Disse egenskapene er inntektskilde og kostnadsreduserende faktor for mer enn 2600 kunder verden over som benytter eller har benyttet FAST ESP plattformen.

FAST Search and Transfer ble kjøpt av Microsoft I 2007. Etter oppkjøpet er det etter hvert blitt klart at FAST ESP ikke blir videreført som selvstendig crossplattform søkemotor. FAST ESP vil imidlertid eksistere i mainstream support fram til 2013 (2015 for kunder med en Licence Grant), og extended support på alle OS plattformer fram til 2018 (2020 for License Grant kunder).

I denne perioden er det fullt mulig og trygt å benytte og til og med utvikle nye tjenester på FAST ESP søkemotor. Vårt team av Application Management Services  (AMS) konsulenter har lang fartstid fra FAST og med FAST ESP plattformen., og har blant annet jobbet med konsulenttjenster, AMS og support internt hos Fast Search and Transfer/Microsoft. Samtidig som vi med våre AMS tjenester kan oppretteholde stabil drift av din FAST ESP plattform, vil vi være aktive rådgivere og løsningsarktekter over på en ny søketeknologi ettersom behovene melder seg.

Vår langsiktige plan med Comperio Front har vært å gjøre våre kunder mindre avhengige av underliggende søkemotor, og situasjonen med FAST ESP viser at dette har vært en god anbefaling. For våre kunder med Comperio Front er vi nå i stand til å tilby effektive  overganger til nye teknologiplattformer, samtidig som bedriftens forretningslogikk og søkemotorens posisjon som  informasjonsnav er ivaretatt i Comperio Front.

Når det gjelder overgangene til nye teknologier i en etter FAST ESP- era er det flere valg og muligheter som åpner seg. For mange tradisjonelle FAST ESP kunder innen ehandel, katalog, rubrikk og media er ikke FAST for Sharepoint nødvendigvis er et naturlig valg for øyeblikket, spesielt ikke dersom man ellers benytter noe annet enn Microsoft teknologi. Comperio har erfaring og dialog med flere kunder om overgang til opensource plattformer og Cloudtjenester som Solr, Elasticsearch og Amazon Cloudsearch, og også Google Custom Search, alt etter behov.

Når dette er sagt er Microsoft’s plan framover å bruke de avanserte egenskapene til FAST i sine produkter videre, både for kontorstøtte i Office/Sharepoint/Exchange/Office365, så vel som i sin søkemotor på internett – Bing. Microsofts release av FAST Search for Sharepoint 2010 er et eksempel på dette, og neste generasjons Microsoft produkter vil vise dette enda tydeligere. For mange FAST ESP kunder i bedriftsmarkedet er det naturlig å følge dette sporet, så lenge det er mulig å bygge de løsningene man ønsker. Og også her er kommer Comperio Front inn som en byggestein for å gjøre det mulig å tilpasse søkebaserte løsninger i Sharepoint på en fleksibel måte.

Microsofts utviklingsteam for søk er lokalisert med basis i FAST R&D avdeling i Torggata Oslo, og samarbeider tett med så vel Bing som Microsoft Office sine utviklingsteam. Med vår nære tilknytning, geografisk, historisk og teknisk fortsetter Comperio å følge FAST/Microsoft i deres videre utvikling, og vårt Microsoft team er hele tiden i Front med det nye som leveres fra Microsoft.

Men først av alt ønsker vi å hjelpe våre kunder til gode søkeopplevelser!

Here’s an interesting article from Beyond Search which looks further into this topic:

Comperio Provides a Safety Net at SharePoint

Entering a Misspelled word during internet search can lead to a few moments of irritation, but in the business world things become even more complicated. Typing one wrong letter can often send users spiraling downward towards a promotional disaster. Fortunately, some providers are hanging up a few safety nets to prevent the fall.

Microsoft just revamped Bing to recognize common errors during internet search.  According to, ‘Bing reveals efforts to help with human search errors Bing will remember key words and phrases most frequently used. To correct issues the search feature itself was altered as:

“We used to show synonyms as part of our recourse links and this would open up some surface area for showing alterations. The query “define interesting” highlights an example where the recourse link was unnecessary.  In this case, showing the Recourse Link didn’t enhance the experience. We’ve removed the Recourse Links in cases where we are very confident that they add little value or distract users.”

Basically, Microsoft created a net to catch errors in advance and Comperio can implement similar functions within SharePoint using Fast technology. The safety net Comperio provides can help catch users before they fall into the uncomfortable realm of presentation faux pas.  They can customize the programming towards the specific needs of the business to increase efficiency.

For more information about Comperio, visit the company website at http://www.comperiosearch.com/.

via Jennifer Shockley, June 27, 2012

Beyond Search