Help Application demo at Lotusphere

[eknori]

Das sieht doch schon mal ganz gut aus, Axel  ...

Ich habe noch ein wenig an der Function GetAllTicketsBySupporter rumgewerkelt.
Den Status habe ich gestrichen, so daß als einziger Input nur der Name des Supporters übrigbleibt.

Außerdem habe ich noch das HELP übliche Errorhandling und Logging eingebaut. ( Dazu müssen die dazu notwendigen Funktionen über Use "lib.appl.functions" eingebunden werden )

Ich weiß, daß die Funktion natürlich eine Menge Docs zurückgeben kann; ist mir aber momentan wurscht. RIM will ja nur demonstrieren, daß die Webservices vom Domino 7 mit ihrem Mobile Data Service zusammenarbeiten.

Die Funktion gibt zusätzlich auch den Dokumentenstatus zurück; danach kann man dann clientseitig auch noch filtern. Außerdem wird ein ErrorCode mitgeliefert ...

%REM
#####################################################
 Public Function GetAllTicketsBySupporter ( ) As TicketCollection
#####################################################
%END REM      
   Public Function GetAllTicketsBySupporter ( strSupporter As String ) As TicketCollection
      
      On Error Goto ERRHANDLE      
      
      If Trim(strSupporter) = "" Then
         Set GetAllTicketsBySupporter = New TicketCollection
         GetAllTicketsBySupporter.TicketCount = 0
         GetAllTicketsBySupporter.ErrorCode = GET_TICKET_ERR_MANDANTORY
         Exit Function ' nothing else to do, get outa here !
      Else      
         
         SearchFormula =_
         |@UpperCase(Form) ="BUGREPORT" & @UpperCase(@Name([CN];supporter)) ="|_
         & Ucase(CommonNameString (strSupporter )) & |"|
         
         Dim dateTime As New NotesDateTime(_
         Cstr(Datenumber(2000, 5, 1)))
         Dim dc As NotesDocumentCollection
         Set dc = db.Search( SearchFormula, dateTime,0)
         
         count = dc.count
         Set GetAllTicketsBySupporter = New TicketCollection
         GetAllTicketsBySupporter.TicketCount = count
         GetAllTicketsBySupporter.ErrorCode = GET_TICKET_ERR_NOERROR
         
         If (count = 0) Then
            Redim GetAllTicketsBySupporter.Tickets(count)
         Else
            Redim GetAllTicketsBySupporter.Tickets(count - 1)
         End If
         
         i = 0
         Set doc = dc.GetFirstDocument
         Do Until (doc Is Nothing)
            
            Set TicketValues = New Ticket
            TicketValues.User = CommonNameString(getItemValue ("user"))
            TicketValues.TicketNumber = getItemValue ("ReqNumber")
            TicketValues.Problem = getItemValue ("problem")
            TicketValues.Status = getItemValue ("status")
            
            Set GetAllTicketsBySupporter.Tickets(i) = TicketValues
            i = i +1
            Set doc = dc.GetNextDocument(doc)
            
         Loop
         
      End If    
      
EXITPOINT:
      Exit Function
ERRHANDLE:
      xProc = Getthreadinfo(LSI_THREAD_PROC)
      xError = xProc  & ": " &Trim$(Str$(Err)) & " on line " & Cstr(Erl) & ": " & Error$
      If UseOpenLog Then
         Call LogError
      Elseif LogScriptErrors Then
         Call ThrowException ( xProc, xError  )
      End If
      Print xError   'In all cases
      If ResumeMethodNext Then
         Resume Next   
      Else
         Set GetAllTicketsBySupporter = New TicketCollection
         GetAllTicketsBySupporter.TicketCount = count
         GetAllTicketsBySupporter.ErrorCode = GET_TICKET_ERR_MISC_ERROR
         Resume EXITPOINT
      End If      
      
   End Function

[eknori]

Axel, du hast mehrfach angedeutet, daß du die Webservices langsam findest ( nehme an, du meinst den Response )

Habe gerade mal ein wenig rumgespielt: Knapp 13 Sekunden braucht der Service, um 583 Tickets abzurufen. Also ich finde, das ist i.O., oder ?

[eknori]

Frage mich gerade, ob es eigentlich sinnvoll ist, die einzelnen Services in einer "Klasse" zu kapseln.
Wenn ich mir so die Dokus dazu anschaue, bauen die für jede Function / Methode einen eigenen Service.
Ich finde das persönlich nicht so toll.

[eknori]

wo habe ich den Denkfehler ?? Hatte ja angedeutet, daß GetNthDocument ( i ) nicht funktioniert. Nach ein wenig Bastelarbeit habe ich folgendes gefunden:

This one doesn't work:


         For i = 0 To dc.Count
            Set doc = dc.GetNthDocument ( i + 1 )
            
            Set TicketValues = New Ticket
            TicketValues.User = CommonNameString(getItemValue ("user"))
            TicketValues.TicketNumber = getItemValue ("ReqNumber")
            TicketValues.Problem = getItemValue ("problem")
            TicketValues.Status = getItemValue ("status")
            
            Set GetAllTicketsBySupporter.Tickets ( i ) = TicketValues
         Next

( doc is not initialized )


BUT this one works like a charme

         For i = 1 To dc.Count
            Set doc = dc.GetNthDocument ( i )
            
            Set TicketValues = New Ticket
            TicketValues.User = CommonNameString(getItemValue ("user"))
            TicketValues.TicketNumber = getItemValue ("ReqNumber")
            TicketValues.Problem = getItemValue ("problem")
            TicketValues.Status = getItemValue ("status")
            
            Set GetAllTicketsBySupporter.Tickets ( i  - 1 ) = TicketValues
         Next   

Isn't it the same ??    

Ich finde einfach nicht den Fehler in meiner Denke; müsste wohl mal wieder Urlaub machen ...

[eknori]

Oh Gott, jetzt wo ich es gepostet habe, sehe ich den Denkfehler auf den ersten Blick... wie peinlich

[eknori]

Und das

         For i = 1 To dc.Count
            Set doc = dc.GetNthDocument ( i )
            
            Set TicketValues = New Ticket
            TicketValues.User = CommonNameString(getItemValue ("user"))
            TicketValues.TicketNumber = getItemValue ("ReqNumber")
            TicketValues.Problem = getItemValue ("problem")
            TicketValues.Status = getItemValue ("status")
            
            Set GetAllTicketsBySupporter.Tickets ( i  -1 ) = TicketValues
         Next

bringt noch einmal einen enormen Performancegewinn : 7 Sekunden für 702 Docs 

[flaite]

Axel, du hast mehrfach angedeutet, daß du die Webservices langsam findest ( nehme an, du meinst den Response )

Habe gerade mal ein wenig rumgespielt: Knapp 13 Sekunden braucht der Service, um 583 Tickets abzurufen. Also ich finde, das ist i.O., oder ?

7 Sekunden find ich eindeutig zu viel. Bin schliesslich kein Websphere-EJB2.0-Entwickler.  Werd auf jeden Fall noch untersuchen, wo er so lange braucht. Meine Idee nur die Tickets runterzuladen, die später verändert worden sind als ein vom Client persistent abgelegter Zeitstempel halte ich nach wie vor für gut. Bin aber auch dafür, erst einmal eine Lösung mit Schwächen anzubieten.

Performance von SOAP ist definitiv ein issue und sowas führt ja heutzutage zu einer Menge von Alternativ-Implementierungen. Macht den Job auch nicht einfacher, ist aber richtig. Das gute an SOAP ist die Toolunterstützung. Beim Programmieren hat man weder auf Client noch auf Serverseite direkt etwas mit xml zu tun.

Zu wissen wie man das in der Not schneller machen kann und die Stellen zu kennen, wo es langsam ist, halte ich für eine wichtige Information. Dafür ein besseres Verständnis, ist ein Grund warum ich das hier alles mache.
Weiss noch nicht, wie HELP funktioniert, aber 583 Tickets in denen mein Name steht, wäre definitiv ein Problem in der realen Welt mit sämtlichen Helpdesksystemen, die ich kenne. Vielleicht eine zu große Zahl.
 

rage mich gerade, ob es eigentlich sinnvoll ist, die einzelnen Services in einer "Klasse" zu kapseln.

Nö. Eine wsdl Datei für sämtliche Funktionen, die irgendwie etwas mit Tickets zu tun haben. Das ist auch für die IDE auf Consumerseite wesentlich einfacher für die Code-Generierung.
Und zudem entspricht das den Design-Ideen der SOA (consultant-buzzword-on-top-of-SOA) wie ich es verstehe. Bin aber in Thomas Erls Bibel mit dem dicksten Bucheinband, den ich seit langen gesehen habe, erst auf Seite 160 von 700 .

For i = 0 To dc.Count
            Set doc = dc.GetNthDocument ( i + 1 )

Ich versuche sowas in jeder Programmiersprache wo möglich zu umgehen. dc.getNextDocument(doc) ist eh schneller.

Gruß Axel

[Thomas Schulte]

Ich denke nicht das es in diesem Fall etwas ausmacht ob das Ganze 7 oder 2 Sekunden braucht um 700 Tickets runterzuladen. Am anderen Ende, zumindest für dieses Beispiel, sitzt, steht oder liegt ein Mensch und der braucht schon einmal länger als 7 Sekunden um überhaupt nur die erste der gelieferten Informationen zu verarbeiten.

Für ein "Maschine to Maschine" Interface macht es dann schon wieder Sinn das Ganze noch etwas zu beschleunigen.

Was die Implementierung von Services angeht hat Axel denke ich teilweise recht. Alles was mit Tickets zu tun hat in eine WSDL packen. ABER nur solange es wirklich zwingend zum Ticket gehört.

[flaite]

@Thomas: Die Anwendung ist zu der Zeit quasi blockiert. Ist so als würde man 10 Sekunden warten, bis eine Webseite geladen ist. Die Tickets kommen in einem Schwung und nicht häppchenweise an.
Da kann man höchstens:
a) einen Balken anzeigen, damit überhaupt was auf dem Bildschirm passiert oder
b) paging, d.h. man implementiert eine neue Webservices Funktion, die die Tickets nacheinander in einer gewissen Stückelung (z.B. 50) runterlädt. Außerdem hab ich jetzt Performance-Tests gegen die Anwendung gemacht. Das sind bei inzwischen vermutlich 2.700 Tickets (s. persönliche Nachricht) bei einem User 34 sec.
SOAP ist so gebaut, dass erst das gesamte SOAP-File empfangen werden muß, bevor da überhaupt nur daran gedacht wird, das weiterzuverarbeiten.

Ulrich, ich hab dir eine persönliche Nachricht geschickt. Mich macht das immer ein bischen nervös, wenn ich die nicht in der Outbox sehe. Hoffentlich ist die angekommen. Thomas, ich schicke die dir jetzt auch.

Axel

[eknori]

Axel,

ja, PM ist angekommen; Kopie in der Outbox ist doch eine Einstelung im Profi.

Wg. der Werte; OK ist halt ein Unterschied, ob das mit 512kB Upstream über DSL läuft, oder im internen Netz mit einigem mehr an Dampf dahinter ...

[eknori]

Zur Performance würde ich mir generell schon Gedanken machen; was allerdings diesen speziellen Fall hier betrifft, werde ich mich mehr auf die Funktionen selber konzentrieren.

Der BB greift ja nicht direkt auf den Domino Server zu; das wird ja über den BES gesteuert. Und der gibt letztendlich die Pakete an den BB weiter. Das könnte also auch schon deutlich performanter sein.
Wie das allerdinds von RIM gesteuert wird, entzieht sich meiner Kenntnis. Aber ich glaube, die wissen schon, was sie tun müssen ...

@Thomas:

wg. der Strukturen mit einem Misch aus Ticket und Todo.

Die TicketCollection beinhaltet ja die Klasse Ticket

Wenn du jetzt noch die ToDo zum Ticket mit übergeben willst, musst du eine neue Klasse ToDoCollection erstellen, die ihrerseits wieder eine Klasse ToDo as Array enthält.

Und die ToDoCollection baust du dann in die Klasse Ticket ein.

Class ToDoCollection
  Public ToDos () as ToDo
  Public ToDoCount as integer
end class

Class ToTo
 Public ToDoNumber as string
end class


Class TicketCollection
   Public Tickets() As Ticket
   Public TicketCount As Integer
End Class

Class Ticket
   Public User As String
   Public TicketNumber As String
   Public Problem As String
  Public ToDoCol as ToDoCollection
End Class

Das sollte dann eine saubere Struktur ergeben ...

[flaite]

Die Idee, dass nur die diff übertragen wird, läßt sich imho wirklich relativ einfach realisieren.

Notes kennt seit 7 offenbar einen neuen Datentyp XSD_DATETIME

SOAP	Java	LotusScript
xsd:dateTime	java.util.Calendar	XSD_DATETIME

Die letzte Tabelle in diesem Artikel:
http://www-128.ibm.com/developerworks/lotus/library/nd7-webservices/index.html

Imho könnte man das in die Search Formula einbauen. Das dort ein Date/Time Wert geschickt wird und dann in der Funktion GetAllTicketsBySupporter nur solche Tickets runtergesendet werden als der DateTime Wert, der der Funktion in einem Bonus-Parameter übergeben wurde.

Arbeite aber erstmal mit dem was da ist.

Im Grunde ist das eine Art selbstgebaute Replizierung.
Auf der Seite des Clients würd ich den Datumswert nach jedem update request gegen den Webservice Request in eine Datei schreiben.

Es erscheint mir wichtig, die Menge der Daten, die am Client ankommen, klein zu halten. V.a. auch, damit der weniger zu tun hat. Diese kleinen Geräte haben ja auch nicht unbedingt so viel processing power wie ein PC. Z.B. könnte man mit Swing die neuen Dokumente wohl auch prima in die existierende Struktur einmischen. Wenn immer alles neu runtergesendet wird, müßte man die gesamten Widgets quasi ganz neu aufbauen. Und Gui-Objekte sind nicht unbedingt klein. Ausserdem sollte dort im Namen von übersichtlichen, erweiterbaren und leicht änderbaren Design eine Zwischenschicht da sein. D.h. die Inhalte der ganzen Objekte der Webservices werden sowieso noch einmal in extra Business Objekte kopiert.
2.700 oder 700 Tickets kann man eh nicht in einem Blackberry anzeigen. Deshalb werd ich für den ersten Client-Prototypen sowieso nur die ersten 10 oder 20 Tickets anzeigen. Das dürfte auch für eine Demo ausreichend sein. Ich hatte im meinem Leben noch nicht mehr als 20 Tickets.

Falls es jemanden interessiert, kann ich das Eclipse Projekt irgendwie über ein peer-to-peer Netzwerk verfügbar machen, wenn ausreichend da ist. Arbeite inzwischen mit Eclipse WTP1.0. Kann als Komplettpaket runtergeladen werden und wirkt stabiler als WTP 0.7.

Ich hab ständig im Hinterkopf, dass in der gesamten Literatur document-style Webservices (und nicht rpc-style) präferiert wird. Im Kontext der Funktion GetAllTicketsBySupporter wird mir auch klar, warum. Bei großen Datenmengen wird einfach alles doppelt und dreifach übertragen, wenn man sich das tatsächliche SOAP-Dokument in SOAPUI oder ähnlichem mal genauer anschaut.
Ist aber erstmal nicht so dramatisch. Domino unterstützt beides.

In der Literatur wird btw. auch davon gesprochen, dass error-codes in einem header-Bereich der SOAP Nachricht gehören. Weiss aber momentan auch nicht wie man das implementiert und nur am Rande. Ist nicht funktional.

Gruß Axel

[Mark³]

du kannst ja mal Quellcode posten vom Swing-Client. Ich würde gern mal einen RCP dafür bauen aber ich weiß nicht ob ich dazu komme (einer muss ja auch arbeiten hier  ).
Diese Baumdarstellung, ist das in Swing schon drin oder musst du das bauen? Im RCP geht das nämlich ganz einfach über JFace TreeViewer...
Hat HELP!!! eigentlich eine CMDB? Die ist nämlich das Herzstück eines jeden TroubleTicket Systems. Wenn nicht, vielleicht kann ich da mal meine Erfahrung einbringen, irgendwann im nächsten Jahr...

Ist WTP 1.0 Eclipse + Web oder fehlt da irgendwas? Sonst kannst du damit ja einfach ein neues RCP-Projekt erstellen und deinen Code da reinziehen.

[eknori]

Hat HELP!!! eigentlich eine CMDB?

Thomas hat da was in der Hinterhand; ist aber noch nicht freigegeben ...

[flaite]

Diese Baumdarstellung, ist das in Swing schon drin oder musst du das bauen?

javax.swing.JTree
Hier ist eine visuelle Übersicht der Swing Widgets:
http://java.sun.com/docs/books/tutorial/uiswing/components/components.html
(die sind besser als die da aussehen, weil die da das unsägliche Metal Look & Feel verwenden. Man kann aber Look & Feels austauschen, wie man bei meinem Beispiel sieht).

Im RCP geht das nämlich ganz einfach über JFace TreeViewer...

Gibt da auch ein Widget, das eine Art Mischung aus Tree und Table ist. Hab aber den Namen vergessen. Das würde Sinn machen. Swing ist aber auch nicht so schlecht.

Hat HELP!!! eigentlich eine CMDB? Die ist nämlich das Herzstück eines jeden TroubleTicket Systems. Wenn nicht, vielleicht kann ich da mal meine Erfahrung einbringen, irgendwann im nächsten Jahr...

Configuration Management Database. Kannte die Abkürzung nicht.

Ist WTP 1.0 Eclipse + Web oder fehlt da irgendwas? Sonst kannst du damit ja einfach ein neues RCP-Projekt erstellen und deinen Code da reinziehen.

ja. Das all-in-one Paket:
http://download.eclipse.org/webtools/downloads/drops/R-1.0-200512210855/
(URL möglicherweise nicht stabil).
Ich hab mehrere Eclipse installiert, die sich diverse Workplaces sharen. So machen das viele. Aber vermutlich weisst du das.
Schick dir das, sobald das stabil ist. Du brauchst auch nicht direkt auf die leicht kuriose, automatisch generierte Schicht von SOAP-Consumer Klassen zuzugreifen, weil da ein Layer von Business Objekten zwischen ist. RCP interessiert mich natürlich auch.

Hab die GUI probeweise mit dem hochgelobten WYSWYG Swing Editor von Netbeans 5.0 beta 2 zusammengeklickt (echt gut). Mußte da nur noch der ihren speziellen Layout-Manager in das Eclipse-Projekt als jar importieren. Werd aber auf Carsten Lentzschs looks & forms umsteigen. Das Projekt ist btw. Java5, aber das sollte keine Probleme machen. Ich stell die verwendete Java Version in Eclipse immer projekt-spezifisch ein.

[Mark³]

das Buch zu RCP ist übrigens sehr gut, besonders das Kapitel 'Objektrelationale Brücken (Hibernate etc.) wird dir gefallen (siehe http://atnotes.de/index.php?topic=24620.msg175496#msg175496)

<Start Fredjacking>
Zur CMDB (ITIL: Configuration Management): Ich hoffe sie ist nicht Notes-basiert  Da würde ich wirklich eine relationale Datenbank bevorzugen, da CMDBs üblicherweise von vielen Anwendungen geteilt werden. Mit OpenLDAP kann man sowas vielleicht gut bauen, das gibt extrem gute Zugriffszeiten
<End Fredjacking>

[Thomas Schulte]

Hat HELP!!! eigentlich eine CMDB?

Thomas hat da was in der Hinterhand; ist aber noch nicht freigegeben ...

Das hängt jetzt davon ab.

Was wir haben ist eine Datenbank für das System Management, in der der Lebenszyklus einer Hardware aufgezeichnet werden kann. Mit der Zuordnung zu Personen, Stellen, ....
Mit Teilen und so weiter.

Was wir auch haben, allerdings Stand alone und noch lange nicht soweit das es sauber in !!Help!! integriert werden kann ist eine Datenbank für Service Level Management. Aus der kann man dann wenn das mal so läuft wie ich mir das vorstelle die Responsezeiten und die Dringlichkeit einer Störung rausholen.

Ich glaub was Mark meint ist eine Zentrale Konfigurations Datenbank. Für die ganze Anwendung und nein, das haben wir nicht.

[flaite]

out of topic:
Für die Integration von Fremdsystemen in Notes (CMDB, SLA-DB) können Webservices definitiv Sinn machen.

[Mark³]

Ich glaub was Mark meint ist eine Zentrale Konfigurations Datenbank. Für die ganze Anwendung und nein, das haben wir nicht.

Tut mir leid, ich denke schon völlig in ITIL. Eine CMDB ist für mich wie oben gesagt die Configuration Management Database. Hier stehen alle Assets drin, das sind im Allgemeinen sämtliche Hardware die inventarisiert ist sowie alle Softwarelizenzen.
In jedem Helpdeskticket gibt es dann zig Relationen zur CMDB:
- Hardware des Users
- bisherige Tickets auf diesen PC
- Kostenstelle des PC-Owners
- Lizenzen die dem PC oder User zugeordnet sind
etc.

[flaite]

Zurück zum Thema.
@Ulrich: Warum hat der zurückgegebene Ticket-Type der Funktion GetAllTicketsByUser Funktion einen Member user?
Der Consumer sendet den Namen des TicketUsers doch schon hoch?

Public Function GetAllTicketsBySupporter ( strSupporter As String ) As TicketCollection ?