Lotus Notes / Domino Sonstiges > Help-Desk Applikation !!Help!!
Help Application demo at Lotusphere
eknori (retired):
Kam gerade rein ...
--- Zitat ---Hello Ulrich,
I am with Research In Motion, the makers of the BlackBerry solution.
We are currently looking to demonstrate at Lotusphere BlackBerry Mobile
Data Services 4.1 support for Domino 7 web services and your application
appeared as a candidate. Do you have any current work to extend the
application using the native D7 web services? Any means to get
development assistance from your team to add this into the application
(at least a few basic functions) in the next few weeks?
Thanks in advance,
Jon
_____________________________
Jonathan Christiansen
Senior Manager, Technical Services
Cingular Business Unit
Rogers Business Unit
Research In Motion Limited
--- Ende Zitat ---
flaite:
Biete ab dem 29.12. meine konstruktive Mitarbeit an. Schau mir das mal an.
Danach sieht es so aus, dass ich bis zum 03.01. auf jeden Fall frei habe, wobei der 1. und weite Teile des 31. natürlich ausfallen. Es sollte aber machbar sein, zumindest teilweise präsentabel zu Webservice-enablen.
Wobei dies vielleicht nicht die ganz hohe SOA Schule sein wird.
Gruß Axel
eknori (retired):
--- Zitat ---Biete ab dem 29.12. meine konstruktive Mitarbeit an
--- Ende Zitat ---
Danke Axel, das Angebot nehme ich sehr gerne an. Habe Jonathan gerade gemailt, daß wir das grundsätzlich können, wir aber noch ein paar mehr Informationen benötigen, welche functions sich die Brombeeren denn so vorstellen ...
Und wenn daß nicht zu abgehoben ist, ( und 3 Freiflüge, FirstClass + Hotel in Orlando dabei rauspringen ) sind wir doch zu allen Schandtaten bereit, oder :D
Scherz beiseite; ist eine Herausforderung, da daß Thema für mich neu ist; aber man kann ja nur dazulernen...
eknori (retired):
@Axel, korrigiere mich bitte, wenn ich vollkommen falsch liege.
Lassen wir einmal die Mails in HELP außer acht; dann bleiben Tickets und Todo.
Also gibt es eigentlich nur 2 ( grosse ? ) Klassen
class Ticket und
class Todo
Nehmen wir die Klasse Ticket
diese enthält dann Public und private functions und subs
eine mögliche function könnte dann sein
public function getAllBySupporter ( sName as String ) as NotesDocumentCollection (?)
wobei das Ermitteln der results dann über private funcs erfolgt...
oder
public function GetSubjectFromTicket ( TicketNum as String ) as string
( hier wäre dann ein
Private Function openDatabase(dbname As String) As Boolean
Set db = s.GetDatabase("", dbname)
If db.IsOpen Then
openDatabase = True
Else
openDatabase = False
msg = "Cannot open database " & dbname
End If
End Function
Private Function openView(viewname As String) As Boolean
Set view = db.GetView(viewname)
If view Is Nothing Then
openView = False
msg = "Cannot open view " & viewname
Else
openView = True
End If
End Function
Private Sub getSubject
If doc.HasItem("Subject") Then
msg = doc.GetItemValue("Subject")(0)
Else
msg = "Document does not have Subject"
End If
End Sub
im Spiel ... )
Das ist jetzt LS; ist aber auch in Java möglich. Das scheint wurscht zu sein, obwohl mein 7er Client immer abschmiert, wenn ich versuche Java Code in einen WS zu pasten ... ( das aber nur am Rande )
Und das wäre dann schon das ganze Geheimnis der WebServices ?? Will meinen; wir coden Functionen ( erwartet Eingabe , schmeisst Wert zurück)
Um mehr muss man sich an dieser Stelle nicht kümmern; wie der Anforderer mit dem Rückgabewert umgeht, ist seine Sache ... ???
Sehe ich das richtig ( vereinfacht ) ?
flaite:
Aus meiner Sicht sollte man ein aufgabenbezogenes externes Interface schaffen, das alle Aufgaben, die man sinnvoll aus Blackberry in Help ausführen könnte, als Service anbietet. In der Praxis würde man natürlich an irgendeiner Ecke anfangen.
Deine Trennung in public und private functions ist schon sauber. D.h. Notes spezifische Dinge wie getView, getDatabase werden private gekappselt.
getAllBySupporter (sName as String) ist schon mal vernünftig. Der Rückgabewert als asDocumentCollection nicht so. Am besten man gibt die Sammlung der Tickets der Person als xml-runter. Später dazu mehr.
GetSubjectFromTicket ( TicketNum as String ) as string hört sich für mich nicht so sinnvoll ist. Warum sollte man sich von Blackberry erst die TicketNum holen und dann das dazugehörige Subject noch mal extra? Webservices sind nicht besonders performant.
Das ist, was mit vernünftiger Granularität der Services gemeint ist. D.h. man sendet am besten einen ganzen Sack der Tickets runter. Oder man sendet ein paar Werte pro Ticket runter, die in einer Ansicht (nicht NotesView) auf Blackberry dargestellt werden können (etwa TicketNum, Datum, Priorität, Subject) etc und hat dann noch eine zweite Funktion, die nach Auswahl des Tickets aus der Blackberry Ansicht das gesamte Ticket zurückliefert (bzw. alle Teile des Tickets, die in Blackberries Detailansicht des Tickets dargestellt werden sollen).
Das interessante ist, dass man ganze Dateistrukturen (ähnlich wie ein struct oder type in LotusScript) als xml darstellen kann auch wenn sie verschachtelt sind.
Und xml kann sowohl von Notes als auch von Blackberry in die proprietäre Objektstruktur (Notes-Objekte oder Blackberry-Objekte) umgewandelt werden. Die Aufgabe auf !!Help!!-Seite wäre dann nur das marshalling/un-marshalling (umwandeln) notes-> xml und xml-> notes.
In TicketService könnten dann noch Funktionen wie solveTicket(TicketDoc) oder createTicket(TicketDoc) angeboten werden. Wobei TicketDoc dann (das gesamte Ticket als xml enkodieren würden) oder (nur ein key (ticketNum) und die Felder, die möglicherweise editiert werden können).
Die doc-lit Webservices machen total Sinn. Und nicht nur die rpc-Webservices, wo man nur Strings, Zahlen und alles einzeln übertragen kann. Bei doc-lit Webservices kann man anwendungs-determinierte strucs (z.B. ticket) hin und herschicken. Das geht mit xml und ist auch nicht so schwierig.
Eine weitere Anforderung wäre natürlich authentification/authorization. Weiss aber nicht wie gut das zur Zeit in Notes unterstützt wird. Die einfachere Möglichkeit wäre ssl. Ansonsten wird da aber auch an einer Art xml-Feldverschlüsselung gearbeitet.
Webservices Interfaces sind nicht Objekt-Orientiert!
Sie sind eigentlich mehr Prozeduren, denen man aber structs als Parameter übergeben kann oder die structs zurückliefern können. Es bringt nichts wenn man sich Subject oder ein paar andere Attribute einzeln vom remote Notesserver holen würde. Besser diese structs-Geschichte. Enterprise Java Beans funktioniert teilweise so, dass man sich einzelne Werte vom entfernten Server runterpopelt. EJB-aficionados kommen dann immer mit den dollen caches. In der Praxis ist das dann aber trotzdem langsam.
Ted Neward hat das mal damit verglichen:
Mit heutiger Technologie dauert es 38 Jahre, um von Pluto hin und zurück zu fliegen.
Auf Pluto gibt es total gutes Bier.
Wieviel Bier würde man mit einem Raumschiff von Pluto mitnehmen?
Soviel man tragen kann und sicher nicht jede Bierflasche einzeln (wie teilweise EJB2.0 in Websphere oder erst ticketNum und dann das dazugehörige Subject).
Hoffe das ist verständlich.
--- Code: ---<ticket>
<topic>
Der Button Neues Ticket in der Ansicht Ticket funktioniert nicht
</topic>
<createDateTime>
03.12.04 10:00:00
</createDateTime>
<creator>
Jupp Derwall
</creator>
<history>
<entry>
<date>
14.12.04 10:30:00
</date>
<user>
Sarah Burdenski
</user>
<content>
weiss nicht
</content>
</entry>
<entry>
<date>
14.12.04 10:35:00
</date>
<user>
Big Boss
</user>
<content>
wenn das nicht in 3 Tagen gelöst ist, gibts Ärger
</content>
</entry>
</ticket>
--- Ende Code ---
Die Umwandlung in diese Struktur ist einfacher als es vielleicht erst aussieht.
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln