Lotus Notes / Domino Sonstiges > Help-Desk Applikation !!Help!!

Help Application demo at Lotusphere

<< < (20/34) > >>

eknori (retired):

--- Zitat ---ch hoffe der Service hat Sylvester überstanden, weil ich heute noch testen will
--- Ende Zitat ---

yep, hat er  ;D

Mir sind gestern selber noch ein paar Dinge aufgefallen. Muss mal überlegen, ob wir das für die Demo noch mit einbauen, oder ob das dann unter limitations fällt.

Beim Schließen eines Tickets ( auch beim Zuweisen oder Annehmen ) werden ja immer Mails losgetreten, die den User oder den neuen Supporter darüber benachrichtigen, was gerade geschehen ist. Die benötigten Strings stehen aber erst im UIdoc zur Verfügung, da die Appl. ja erst dann weiß, wer mit welcher Sprache vor der Kiste sitzt. Das ist natürlich im Background nicht möglich.
Man müsste also immer noch den BB User und seine Sprache mit übergeben. Den Rest kann man dann über die Sprachdokumente auslesen.
Evt. ist das auch möglich, nur die ID des BB devices zu übergeben. Muss Mittwoch mal in der Firma gucken, ob man mit der Info irgendwie etwas us dem BES auslesen kann ( steckt ja im Prin zip nur eine SQL DB dahinter )
Das wäre dann aber auch schon wieder sehr speziell auf den BB zugeschnitten und nicht mehr universell einsetzbar ...

Auch die LogActions, die die Historie ( irgendwann ) einmal ersetzen werden, sind Vordergrund methoden.
Da werde ich mich gleich noch hinsetzen, und entsprechende Hintergrundmethoden schreiben.


--- Zitat ---was im Webservice als "TICKETNUMBER" bezeichnet wird, immer id benamsen.
--- Ende Zitat ---
yo, ändere ich ab


--- Zitat ---@Ulrich: Du kannst vielleicht die Blackberry Leute fragen, ob die damit etwas anfangen können. Erleichtert vielleicht Verständnis und Arbeit.
--- Ende Zitat ---
So wie ich das verstanden habe, haben die eine eigene Entwicklungsumgebung für den MDS; da können die sich die Sachen aus dem WSDL zusammenklicken ...


--- Zitat ---Vor allem stellt sich bei mir eine supporter/user Verwirrung ein.
--- Ende Zitat ---

User ist der wo fragt und
Supporter ist der wo die Frage beantwortet / Lösung anbietet

Was die Returns bei den Fehlern angeht ... Mir ist erst einmal wichtig, daß verschiedene Dinge überhaupt erst einmal abgefangen werden; Ich denke, entsprechende Fehlernummern mit einer Beschreibung ( ;D ) reichen aus, um das auf dem BB device entsprechend anzuzeigen ...

flaite:

--- Zitat von: eknori am 01.01.06 - 10:55:11 ---Beim Schließen eines Tickets ( auch beim Zuweisen oder Annehmen ) werden ja immer Mails losgetreten...

--- Ende Zitat ---
Wer kennt das nicht. computeWithForm()  ???

--- Zitat ---
--- Zitat ---was im Webservice als "TICKETNUMBER" bezeichnet wird, immer id benamsen.
--- Ende Zitat ---
yo, ändere ich ab

--- Ende Zitat ---
WAIT. Aber bitte nicht vor dem ersten Integrationstest  ::)
Ich muß dann wieder die stubs regenerieren.


--- Zitat --- da können die sich die Sachen aus dem WSDL zusammenklicken ...

--- Ende Zitat ---
Ich hab ja selber hier quasi eine Klickie-Klickie Umgebung, aber das deckt meist nur 80% ab. Vielleicht hilft lauffähiger code ihnen, die restlichen 20% schnell zu implementieren.

--- Zitat ---Ich denke, entsprechende Fehlernummern mit einer Beschreibung ( ;D ) reichen aus, um das auf dem BB device entsprechend anzuzeigen ...

--- Ende Zitat ---
Ja klar. Ich wollte damit nur sagen, dass Webservices afaik einen eigenen Mechanismus haben, der möglicherweise einfacher ist.

eknori (retired):

--- Zitat ---WAIT. Aber bitte nicht vor dem ersten Integrationstest  Roll Eyes
--- Ende Zitat ---

OK, ich warte jetzt sowieso erst mal auf ein Feedback von RIM; habe Jon gestern die Version zum Testen zugeschickt, wie sie momentan vorliegt ...

eknori (retired):

--- Zitat ---Wer kennt das nicht. computeWithForm()
--- Ende Zitat ---
sure, aber dann weiß ich trotzdem noch nicht, welche Sprache angezogen werden soll.

Da die Demo aber eh in english abläuft, werde ich das für en einbauen ...

flaite:
Noch eine Kleinigkeit. Weil Ticket.Status und TicketDetails.Status jeweils eine Zahl runterliefert, sollte es besser int sein. Das ist einfach klarer.
Ich konvertier das hier unten nämlich sowieso wieder in int um.

--- Code: ---ticketV.setStatus(Integer.parseInt(ticketWs.getSTATUS()));
ticketV.setStatusCode(Integer.parseInt(ticketWs.getSTATUS()));

--- Ende Code ---
ich mein das Integer.parseInt().
Kann das auch nicht einfach in String lassen, weil sich daraus ansonsten eventuell bei weiteren Stati die bekannten Sortierungsprobleme ergeben (3 wird hinter 21 sortiert, wenn nach String sortiert wird).

Ich map die Statuscodes übrigens in einer sprachspezifischen properties-Datei:
z.B.:

--- Code: ---translations_de.properties:
status0=neu
status1=offen
status98=bearbeitet
status99=geschlossen

--- Ende Code ---
oder:
in translations_en.properties

--- Code: ---status0=new
status1=open
status98=resubmited
status99=closed

--- Ende Code ---
So kann man in Java internationalisieren(Klasse RessourceBundle). Er zieht bei mir automatisch die _de Datei, weil das eine deutsche Version von Windows XP ist. Aber das nur am Rande.

Ich tendiere dazu, es besser zu finden, dass im Webservice Producer die Funtktion CreateTickets mit CreateTickets(TicketDetails ticketDetails) implementiert würde und nicht CreateTicket(String userName, String Problem). Das würde mehr Flexibilität geben. Teile des TicketDetails-Objekts können ja unten leer bleiben und im Producer gefüllt werden. Wenn man dann im Webservice Producer doch ein zusätzliches Property vom Client braucht, müßte man nicht die Parameter der Funktion enden, aber das nur am Rande. Stört so erstmal nicht weiter.

Gruß Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete