Archive for: ‘August 2012’

Social Sharepoint? "Gap will only get wider by the time SharePoint 2013 is released"

13. August 2012 Posted by Stefan Pfeiffer

A quote out of a posting on the SharePoint 2013: 7 Features Users are Going to Love:

The social features announced in this SharePoint 2013 preview — though representing the arrival of SharePoint a s a legitimate social platform contender — are nevertheless behind the state of the market today and this gap will only get wider by the time SharePoint 2013 is released to the market. This gap won’t matter to organizations that are committed to the SharePoint platform who will tolerate feature shortcomings in exchange for tight integration of "good enough" social capabilities into SharePoint.

Domino To Go, Notesbook and Lotus Domino featured on Appcelerator Titanium’s Developer Blog

13. August 2012 Posted by Julian Buss

I talked with some guys over at Appcelerator about YouAtNotes, Domino To Go, NotesBook and IBM Lotus Notes and Domino and they wrote a nice blog post about it. Nice to have some visibility outside the ...

IBM stärkt Softwaregeschäft der Partner

13. August 2012 Posted by IBM Press Releases - All Topics - Germany

Geschäftspartner können dank BPLM (Business Partner Led Model) und IBM Solution Accelerator Incentive ihr Portfolio zielgenauer auf die spezifischen Anforderungen ihrer Kunden und Märkte anpassen.

REST Services mit der XPages Extension Library

13. August 2012 Posted by Thomas Ladehoff

Domino-Designer-Logo-small.png
Die Benutzung von REST-basierten Services ist eine sehr schöne Möglichkeit andere Systeme und Anwendungen mit dem Lotus Domino Server zu integrieren.

Dieser Blogeintrag fasst die Bedeutung und Vorzüge von REST im Allgemeinen zusammen und zeigt die Grundlagen der Benutzung der REST Controls innerhalb der XPages Extension Library.

REST-basierte (oder RESTful) Webservices sind sowohl für Integrationsszenarios nützlich als auch zur Vorhaltung von Daten für externe Anwendungen.
Ich benutzte die REST Services zum Beispiel kürzlich, um eine Schnittstelle für eine mobile Anwendung zu realisieren.

RESTful Webservices (Falls Sie sie noch nicht kannten..)


Representational State Transfer (REST) bezeichnet einen Software-Architekturstil, der von Roy Thomas Fielding in seiner Dissertation beschrieben wurde und der Architektur des Internets entspricht. Genauer gesagt ist das im Internet und durch RESTful Webservices verwendete HTTP-Protokoll eine Implementierung des REST-Architekturstils.

Wenn Sie also die Prinzipien des HTTP-Protokolls kennen, wissen Sie auch schon viel über REST. Um die wichtigsten Punkte zu nennen:
  • Informationen werden mittels sogenannter Ressourcen zu Verfügung gestellt. Jede Ressource kan eindeutig über eine ID angesprochen werden (die URL).
  • "Respresentational" meint das Übertragen der Informationen in verschiedenen Repräsentationen, also Formaten. Das heißt sowohl im technischen Sinne (z.B. JSON, XML) als auch im inhaltlichen Sinne (z.B. Text, Bilder).
  • Zustandslosigkeit. Der Server behält keinen (Session-) Status über eine Folge von Requests.
  • Ressourcen können Verknüpfungen zu anderen Ressourcen enthalten, wodurch eine Navigation ermöglicht wird.
  • Die Operationen, die auf einer Ressource ausgeführt werden können, sind generischer Form. Typischerweise werden folgende vier verwendet:
    • GET - lesender Zugriff auf eine Ressource, frei von Seiteneffekten
    • POST - Erstellen einer neuen Ressource
    • PUT - Erstellen oder Aktualisieren einer bestimmten Ressource (bestimmte ID)
    • DELETE - Löschen einer Ressource

RESTful Webservices stellen einen auf HTTP basierenden Service bereit, der den genannten Prinzipien folgt.


Einige generelle Vorteile von RESTful Webservices sind:
  • Loose Kopplung von Anwendungen und Systemen (führt zu hoher Interoperabilität)
  • Einfaches Ressourcen-orientiertes Konzept mit wenigen generischen Methoden
  • Gute Skalierbarkeit
  • Einfaches Caching

Im Wesentlichen sind dies auch die Vorzüge des HTTP-Protokolls.



REST-basierte Services zum Zugriff auf Domino-Daten


Eine gute Übersicht über die REST-Funktionen in der Extension Library bietet das Video "REST Services for Domino and XPages" auf der Extension Library Homepage.
An dieser Stelle werde ich insbesondere die Benutzung der XPages Controls für REST vorstellen. Es gibt noch zwei alternative Wege, die außerhalb des XPages Kontext funktionieren (Benutzung des Domino Data Service und Erstellen eines Custom Servlets).

Es gibt verschiedene XPages Controls, die man zum Zugriff auf Domino-Daten benutzen kann. Zum Beispiel:
  • Database Collection Service (xe:databaseCollectionJsonService): Abrufen einer Datenbankliste auf dem Server.
  • View Collection ervice (xe:viewCollectionJsonService): Abrufen einer Liste von Ansichten und Ordnern in einer Datenbank.
  • View Service (xe:viewJsonService): Lesen von Ansichts- und Ordnerdaten (mit Filterung), Erstellen, Aktualisieren und Löschen von Dokumenten (begrenzt).
  • Document Service (xe:documentJsonService): Operationen auf Dokumenten.

Wie Sie vielleicht erahnen, steht das "Json" innerhalb der Tags der Controls für das verwendete Übertragungsformat JSON.

Beispiele der Controls können auch in der Beispieldatenbank innerhalb des Extension Library Downloads gefunden werden.

Für die XPages REST Controls ist es nicht erforderlich etwas auf dem Domino Server zu konfigurieren (aber es bringt eine kleine Vereinfachung, wie wir später sehen werden).
Es genügt eine XPage zu erstellen und die gewünschten REST Controls hinzuzufügen, um Zugriff auf die gewünschten Daten zu ermöglichen.

Um dies detaillierter zu zeigen und die wichtigsten Paramter zu erklären, werden wir ein einfachen Beispielszenario mit einer Maske "company" und einer Ansicht "companiesByName" verwenden.

Die Services, die wir benötigen, um in bequemer Weise mit den Firmendokumenten zu arbeiten sind:
  • xe:viewJsonService (Auflistung bestehender Firmen)
  • xe:documentJsonService (Erstellen, Lesen, Aktualisieren, Löschen bestimmter Firmendokumente)

Es ließe sich auch der View JSON Service zum Ändern von Dokumenten benutzen. In diesem Fall ist man jedoch auf die Felder im Dokument beschränkt, die direkt einer Ansichtsspalte zugeordnet sind.
Mit dem Document JSON Service lassen sich sogar Rich Text Felder und Anhänge lesen und bearbeiten.



Zugriff auf die Ansichtsdaten


Wir starten mit einer leeren XPage und dem Hinzufügen eines REST Service Controls (siehe Screenshot)
A picture named M2


Einige Eigenschaften dieses Controls:
  • ignoreRequestParams: Parameter in der URL werden für den REST Service ignoriert (analog zu der gleichnamigen Eigenschaft der XPages Datenquellen)
  • pathInfo: Dieser String identifiziert den Service auf der XPage. Für den View JSON Service in diesem Beispiel ist diese Eigenschaft "companies".
  • service: Hier wird der konkrete REST Service angegeben, einer der Services aus der Liste (siehe Screenshot). Im Beipiel der "xe:viewJsonService".


Die Eigenschaften des View JSON Service sind über die hinterlegten Beschreibungen schon fast selbsterklärend. Trotzdem hier ein paar wichtige:
  • columns: Für diese Eigenschaft werden Elemente vom Typ "xe:restViewColumn" angegeben, welche wiederum eine Eigenschaft "columnName" (Referenz zur Ansichtsspalte) und "name" (Eigenschaftsname des JSON Objekts in der Ausgabe). Letzteres Mapping wird nur bei GET Requests angewendet. Außerdem gibt es hier noch eine Eigenschaft "value", die zur Berechnung einer Wertes benutzt werden kann.
  • defaultColumns: Wenn "true", werden alle Spalten der Ansicht in die Ausgabe einbezogen.
  • systemColumns: Spezielle System Spalten, die nicht notwendigerweise als benutzerdefinierte Spalten angegeben sein müssen (z.B. UNID, Maskenname, Anwortdokument (ja/nein)).
  • viewName: Name der Ansicht, die für diesen REST Service benutzt werden soll.

Außerdem gibt es einige Eigenschaften zur Filterung der zurückgegebenen Ergebnisliste, wie z.B. "start" und "count" zur Realisierung von Paging, oder "search" zur Volltextsuche.
Auch Ereignisse zur Reaktion auf Dokumentenereignisse, wie "querysaveDocument" stehen zur Verfügung. Diese werden weiter unten erklärt.

Der folgende Screenshot zeigt die View Service Eigenschaften, die in diesem Beispiel benutzt wurden:
A picture named M3




Testen der API


Um auf den Service zuzugreifen, muss der für die Eigenschaft "pathInfo" angegebene String verwendet werden. Das generelle URL Schema im XPages Kontext ist:
http://{Host}/{Datenbank}/{XPage Name}/{pathInfo}/unid/{unid}?{Parameter}

Für den View Service in diesem Beipiel ist es nicht erfoderlich auf einzelne Dokumente zuzugreifen, daher kann der UNID-Teil weggelassen werden.
Angenommen, die Datenbank heißt "Test1.nsf" und die XPage "data.xsp", so wäre die URL:
http://localhost/Test1.nsf/data.xsp/companies

Die URL kann direkt über den Browser aufgerufen werden (impliziert Request-Methode GET) und die Einträge in der Ansicht sollten im JSON Format angezeigt werden.

Für diesen Zweck und zum weiteren schnellen Testen der API gibt es ein schönes Firefox Add-on mit dem Namen RESTClient. Damit lassen sich benutzerdefinierte Requests erstellen durch Angabe von HTTP-Methode, URL, Request Header und Request Body. Nach dem Senden der Anfrage wird die Antwort vom Server angezeigt.

Der folgende Screenshot zeigt die Antwort für den View Service "companies" im RESTClient:
A picture named M4



In der Antwort sind JSON-Eigenschaften mit einem '@' am Anfang enthalten. Diese markieren Systemspalten (nicht-benutzerdefinierte Spalten).
Die verschiedenen Datentypen werden in verschiedenen Formaten dargestellt, z.B. werden Strings in Anführungszeichen eingeschlossen, Zahlen nicht.
Eine detaillierte Beschreibung über diese und weitere Formate ist in der Dokumentation zu finden (Datei "DominoDataServiceDoc.zip" im Extension Library Download).


Arbeiten mit Dokumenten


Um ein API für einzelne Dokumente zur Verfügung zu stellen, muss ein zweites REST Service Control zu der bestehenden XPage hinzugefügt werden. Diesmal wird die "pathInfo"-Eigenschaft entsprechend dem Zugriff auf ein einzelnen Firmendokument benannt, z.B. "company". Der konkrete Service ist der Document Service (xe:documentJsonService):

A picture named M5



Die folgenden Eigenschaften sind gesetzt:
  • compact: Bei "true" enthält die Ausgabe keine nicht sichtbaren Zeichen.
  • defaultItems: Bei "true" werden alle Items sowie einige Metainformationen in die Ausgabe aufgenommen.
  • formName: Name der Maske, die zum Erstellen von Dokumenten verwendet werden soll.

Um den neuen Service zu Testen lässt sich wieder der RESTClient oder direkt der Browser verwenden (die UNID kann aus der View Service Antwort kopiert werden):
http://localhost/Test1.nsf/data.xsp/company/unid/56A63CD8312606F8C1257A54004009DD

Das Ergebnis sollte nun alle Felder des Dokuments enthalten, sowie einige Metainformationen (z.B. @unid, @form, $UpdatedBy).

Der nächste Schritt besteht im Aktualisieren eines bestehenden Dokuments. Aktualisieren wird für gewöhnlich über die HTTP-Methode PUT durchgeführt. Die Extension Library Implementierung macht hier noch eine weitere Unterscheidung: Die PUT-Methode wird zum Ersetzen des bestehenden Dokumenteninhalts mit den Daten im Request verwendet, wobei vorheriger Inhalt verworfen wird. Das Dokument wird anschließend genau die Daten enthalten, die im Request gesendet wurden.
Aber in den meisten Fällen wird man vermutlich nur einige Items ändern wollen und den Rest des Inhalts unberührt lassen. Dies wird in der Extension Library über eine weitere HTTP-Methode "PATCH" realisiert.

An diesem Punkt ist es erwähnenswert, dass der Domino Server in der Voreinstellung nur die Mehtoden GET und POST unterstützt. Die weiteren Methoden zu erlauben ist eine Einstellungssache in einem Internet Site Dokument, allerdings gibt es noch einen alternativen Ansatz, der auch dann sehr nützlich ist, wenn auf Client-Seite keine PATCH Requests unterstützt werden:
Die HTTP-Methoden PUT, PATCH und DELETE können alternativ auch durch die POST-Methode ersetzt werden und ein zusätzlicher HTTP Header "X-HTTP-Method-Override" kann gesetzt werden, der dann die zu verwendende Methode spezifiziert.

Wie lässt sich also das Ändern eines Items in einem bestimmten Dokument mit Hilfe des RESTClient testen?

1. Setzen des "Method-Override" Header
Im RESTClient von der Titelleiste folgenden Punkt wählen: Headers -> Custom Header
Der folgende Dialog sollte wie folgt befüllt werden:
A picture named M6


2. Es gibt noch einen weiteren Header, der gesetzt werden muss. Ansonsten wird die Anfrage mit einem Fehler quittiert:
Es geht um den "Content Type" der Anfrage, der das JSON-Format angeben muss.
Header Name: Content-Type
Header Wert: application/json

3. Ein bestehendes Dokument per GET abrufen (nur um Daten zum Ändern zu haben).

4. Die Request-Methode auf POST ändern und die korrekte Angabe der Header prüfen (siehe auch folgender Screenshot).

5. Im Request Body die zu ändernden Daten angeben (im JSON Format).
A picture named M7



6. Per "Send" die Anfrage abschicken. Wenn es keine Fehlermeldung gibt, kann das Ergebnis mit einem erneutem GET überprüft werden.


Andere Operationen:
  • Erstellen eines neuen Dokuments: Setzen der HTTP-Methode auf POST (ohne X-HTTP-Method-Override Header)
  • Löschen eines Dokuments: Setzen der HTTP-Methode auf DELETE (oder Methode POST und X-HTTP-Method-Override Header auf DELETE)



Programmatisch die Funktion des Document Service erweitern


Wenn Sie einen Ansatzpunkt zur programmatischen Erweiterung der Request-Verarbeitung benötigen, besteht eine Möglichkeit darin die Dokumentenereignisse, wie "querySaveDocument" zu verwenden.
Auf diesem Weg können zusätzliche Aufgaben durchgeführt werden und Dokumenteninhalt geändert oder ergänzt werden.

Die folgende Liste bietet eine Übersicht über die Parameter der verschiedenen Methoden:
  • queryNewDocument: Keine Parameter
  • queryOpenDocument: Parameter 'id' (Typ String)
  • querySaveDocument: Parameter 'document' (Typ lotus.domino.Document)
  • queryDeleteDocument: Paramter 'id' (Typ String)
  • postNewDocument: Parameter 'document' (Typ lotus.domino.Document)
  • postOpenDocument: Parameter 'document' (Typ lotus.domino.Document)
  • postSaveDocument: Parameter 'document' (Typ lotus.domino.Document)
  • postDeleteDocument: Paramter 'id' (Typ String)

Wenn die Request-Verarbeitung abgebrochen werden soll, bieten alle Methoden, deren Name mit "query" beginnt, einen boolesche Rückgabewert. Wird 'false' zurückgegeben, so wird eine Exception geworfen und eine entsprechende Fehlernachricht wird zum Client gesendet. Wenn 'true' zurückgegeben wird, so wird die Verarbeitung fortgesetzt.

Für noch mehr Kontrolle über die Verarbeitung und die generierte Ausgabe gibt es außerdem die Möglichkeit, ein Custom Servlet zu schreiben. Wie das funktioniert wird Thema eines zukünftigen Blogeintrags sein.

Notes: Shortcut des Tages

10. August 2012 Posted by Stefan Gebhardt

Bei lekkimworld.com wurde ich im Blog mal wieder an den eigentlich praktischen Tastaturbefehl "ctrl-shift-l" erinnert - dieser listet die "Shortcuts" des Notes-Client auf. Geht sogar auch auf dem Mac - dort ist es "shift-cmd-l". Schon erscheint die Liste mit den verfügbaren Tastaturbefehlen: ...

Extension aus Dateinamen in Java extrahieren.

10. August 2012 Posted by Ralf Petter

Oft möchte man die Extension eines Dateinamens extrahieren. Dies ist mit den Funktionen der String Klasse sehr leicht möglich.

Entweder man macht sich eine statische Methode.

public static String getExtension(String fileName) {
int pos = fileName.lastIndexOf(".");
return fileName.substring(pos + 1);
}
Oder man nimmt den Einzeiler

fileName.substring( fileName.lastIndexOf(".") + 1);


Die Funktion geht aber davon aus, dass es eine Extension gibt. Andernfalls müsste man noch Fehlerbehandlungscode einbauen.

Systemzeit – Downtime EULUC

9. August 2012 Posted by Jörg Allmann

Am Montag, 13.8., wird die EULUC-Plattform zwischen 8:00 und ca. 11:00 nicht zur Verfügung stehen. Wir werden in dieser Zeit ein Update auf das Release 3.0.1.1 CR2 durchführen. Wir bitten um Verständnis, aber es dient ja alles einem guten Zweck.

August Webcast OpenSocial Bedutung für Notes, WebSphere Portal und Connections

9. August 2012 Posted by Axel Sass

Hi,

der August Webcast hatte zum Thema:

 

OpenSocial Gadgets Bedeutung für Notes, Connections und WebSphere Portal.

 

Anbei finden Sie den Link zu der Präsentation und der Screencam des Webcasts:

PDF der Präsentation

Screencam

Sollten Sie nicht dabei gewesen sein können, wünsche ich Ihnen viel Spass bei dem nachträglichen Anschauen. Sollte Sie noch Fragen haben, wenden Sie sich bitte an mich ( axel.sass@de.ibm.com ).

Mit freundlichen Grüßen

Axel Saß

 

 

DNUG — The Enterprise Collaboration Association

9. August 2012 Posted by Petra Schubert

Hier noch einmal eine leichte Anpassung des bisher beliebstesten Vorschlags.

Der neue Namensvorschlag besteht aus zwei Teilen:
1. Dem Fachgebiet/Interessensgebiet (Enterprise Collaboration)
2. Dem Typ des Zusammenschlusses (bisher vorgeschlagen: Professionals)
 
Ich denke, Enterprise Collaboration ist ein ideal neutraler Begriff, der Produkt-agnostisch ist und über mehrere Jahre beständig sein sollte. Insofern: sehr gut.
 
Der zweite Teil des vorgeschlagenen Namens erscheint mir als täglich englisch sprechender Mensch nicht so ideal. Professionals heißt wörtlich übersetzt "das Fachpersonal". Es kann zwar auch für einen Berufsverband stehen, hat aber m.E. die Konnotation eines Anbieters (a la "wir bieten die Services unserer Mitglieder für Unternehmen an") und das ist es ja nicht, was wir tun. Deshalb wäre mein Alternativvorschlag ganz einfach "Association". Das ist der offizielle Name für Vereine (und das ist die DNUG ja sogar im rechtlichen Sinne).
 
Insofern mein leicht angepasster Vorschlag: DNUG – The Enterprise Collaboration Association (natürlich auch als Englisch/Deutsch Gemisch mit "Die Association" möglich).
 
ECA könnte man sogar aussprechen, falls wir langfristig DNUG als Abkürzung ablösen wollen.

Suche C4 Freunde, biete . . .

8. August 2012 Posted by Joachim Haydecker

Bild

IBM hat auf Greenhouse Connections 4 oder Next installiert.

Und das Erlebnis des Testens wäre noch um einiges größer, wenn ich noch mehr C4 Freunde hätte. 

Daher: Jeder der sich mit mir auf Greenhouse anfreundet, der bekommt auch den Link auf die Neuerungen der kommenden Connections Version.

(OK, ist nicht wirklich das riesen-geheime Geschenkt, aber als Willkommensgeschenk genau das richtige).

IBM PartnerCamp 2012 in Ehningen

8. August 2012 Posted by Barbara Koch

am 11.September findet bei IBM Ehningen das PartnerCamp 2012 statt, Anmeldung und Co via http://www-05.ibm.com/de/partnercamp/index.html

Seiwert-Tipp der Woche: Niemals "out" – gutes Benehmen

8. August 2012 Posted by Roswitha Boldt

 

Ob Sie nun chatten, im Supermarkt einkaufen oder im Restaurant essen - die Grundregel für gutes Benehmen ist einfach: Behandle andere so, wie du selbst behandelt werden möchtest.

Bieten Sie von sich Hilfe an und nehmen Sie Rücksicht auf andere. Dazu gehört, in der S-Bahn den Sitzplatz für eine alte Dame freizumachen; nach 20 Uhr keine geschäftliche SMS mehr zu verschicken, die den Empfänger am Feierabend stört; beim Essen das Handy nicht auf den Tisch zu legen und während einer Unterhaltung den iPod aus dem Ohr zu nehmen. Haufenweise Tippfehler sind in geschäftlichen E-Mails ebenso unangebracht wie Vordrängeln beim Bäcker, das vorschnelle Duzen von Fremden oder Telefonieren beim Bezahlen an der Kasse.

 

Mit freundlicher Genehmigung der SEIWERT KEYNOTE-SPEAKER GMBH


Weitere Anregungen, Lese- und Seminarempfehlungen

 

Re: DNUG – die Enterprise Collaboration Professionals –

8. August 2012 Posted by Joachim Bernert

Als Antwort auf: DNUG - die Enterprise Collaboration Professionals -

Ich schließe mich voll der Meinung von Prof. Nastansky an.
Warum sollte man den Namen ändern, nur weil er Deutsch und Notes enthält ?
Die Geschichte der "DNUG" kann man beispielsweise auch ergooglen.
Gezählt habe ich die große Anzahl der gefundenen Einträge nicht.
Warum sollte man diesen wertvollen Fundus den IT Historikern überlassen?
Ich meine auch, dass man die bekannten Begriff "DNUG" nicht aufgeben sollte, weil ... siehe Prof. Nastansky.
Für die Änderer in unseren Reihen könnte sich die Internetadrese DNUG.DE im Domänennamen ändern in . ORG, NET, .COM , .INFO ...
Dann ist wenigsten "Deutsch" weg im Domänennamen, wenn es denn sein muss.
Ich würde jedoch bei DNUG.DE bleiben, denn hier liegen die Wurzeln, die Initiativen und die Organisation.
Der Markenname DNUG wird, wie Prof. Nastansky richtig sagt, ein Eigenleben entwickeln.
Dazu ein Beispiel:
In der DDR gab es ein Kombinat (analog einem Konzern) mit dem Namen SKET.
Dabei stand SKET für Schwermaschinenbau-Kombinat Ernst Thälmann.
Ernst Thälmann war ein kommunistischer Arbeiterführer.
Die Firma SKET hatte fast ausschließlich erfolgreich für den Export gearbeitet und besaß damit einen sehr bekannten und guten Namen.
Heute gibt es mit gleichem Logo und Namen diverse Firmen, die nirgendwo auf ihrer Webseite den Namen SKET erklären:
- SKET Verseilmaschinenbau GmbH
- SKET Industriepark GmbH
- SKET EDV GmbH
- ....
SKET ist eben eine Marke geworden, die bekannt ist. ein Eigenleben entwickelt hat.
Mit einen Zusatz profitieren mehrere Firmen von dem Markennamen.
Ein ähnliches Konstrukt wäre auch bei der DNUG denkbar.

Doclink ist nicht gleich Doclink

8. August 2012 Posted by jNotes RSS

Im Alltag mit Lotus Notes wird gerne mit Doclinks gearbeitet, jenen praktischen Verknüpfungen zu Dokumenten, Ansichten oder Datenbanken. Ein Mailempfänger kann so beispielsweise sehr schnell an wichtige Informationen kommen. Die schnelle Informationsbeschaffung...

Case Study: Omron Europe launches next-generation intranet experience

8. August 2012 Posted by Stefan Pfeiffer

In the past, Omron Europe, a global leader in the field of industrial automation, functioned as a multilocal firm, but with globalization customers are more likely to  do business across country borders. So first the company needed to remove geographic obstacles to become a Pan-European organization. Second, Omron Europe was split into two divisions, with separate sales  and marketing teams serving many of the same customers. Better communications and collaboration across divisions would help ensure that customers recognized the company as “one Omron.” And a social business network could enable salespeople to share leads and information about common customers, leading to better opportunities for all.

“We are much more than the sum of our parts,” says Michel Min, strategic communication and e-marketing manager, Omron Europe. “That was  the driving force behind creating a portal and social business network to better share knowledge and experience and to strengthen the flow of  information across all departments and geographies. Our ultimate goal was not just knowledge transfer from one employee to another but to transfer organizational knowledge and expertise to the customer as quickly as possible.”

Download full case study.

[Originally posted on http://ibmsocialbiz.tumblr.com/]