AutoResponder mit Fiddler

By Henning Eiben in Development 0 Comment

Vor einigen Tagen sollte ich einen Proof-Of-Concept erstellen, ob man ein System XYZ z.B. in BizTalk anbinden könnte. Das System XYZ bietet dazu eine Schnittstelle an, welche über HTTP mit JSON Nachrichten angesprochen werden kann und auch mit JSON wieder antwortet.

Also mal eben eine kleine BizTalk-Lösung bauen, um zu testen ob man diese JSON Nachrichten richtig erstellen und die Antworten auch richtig verarbeiten kann. Als erstes wird in Azure eine BizTalk 2013 R2 Entwicklungsumgebung erstellt. Das geht recht schnell, innerhalb von knapp 15 Minuten ist die Umgebung verfügbar – cool.

So, also nächstes musste also die Lösung erstellt werden. Aber die Frage ist: wie kann ich testen, ob nun aus BizTalk die Services richtig angesprochen werden und auch die Antwort dann von BizTalk richtig verarbeitet wird? Das System XYZ läuft beim Kunden On-Premise, da habe ich also von Azure aus keinen Zugang. Und mal eben XYZ installiert ist ja auch nicht so einfach, da brauche ich einen SQL-Server, Tomcat … und das ganze Konfigurieren – und alles nur für einen Proof-Of-Concept? Nein Danke!

Und mal wieder ist Fiddler der Retter!

Ich habe also meine Lösung mit BizTalk gebaut und dann auch komplett im BizTalk deployed. Nur leider steht mir ja das System XYZ nicht zur Verfügung, welches in eigentlich ansprechen wollte. Also mal eben Fiddler auf dem Server installiert und dann mit Fiddler das System simuliert. Anstatt dem System XYZ hat Fiddler auf die Aufrufe, welche für XYZ bestimmt waren, abgefangen und beantwortet. Für BizTalk erfolgte das komplett transparent – sweet!

Und wie geht das?

Ganz einfach! Fiddler hat eine Funktion „AutoResponder“. Damit kann Fiddler automatisch auf eingehende Nachrichten reagieren und antworten. Hier haben ich also für die HTTP Aufrufe entsprechende Regeln eingerichtet, die zum einen überprüfen ob die URL http://system-xyz:9090/abc/ aufgerufen wurde und ob im Body des Requests clazz=foo steht. Wenn ja, dann wird der Inhalt der Datei foo_response.json zurückgefliefert. Mit einer zweiten Regeln prüfe ich dann analog ob im Body clazz=bar steht und antworte mit bar_response.json.

fiddler_01

Alle anderen Anfragen werden ganz normal weitergegeben. Für BizTalk ist es also vollkommen transparent, ob nun das System XYZ oder ein anderes tatsächlich auf die Anfragen reagiert. Es muss ja noch nicht einmal der Server-Name existieren, da der Request ja direkt von Fiddler abgefangen wird.

Cool! Somit kann ich testen, ob meine Anwendung richtig mit dem System XYZ sprechen würde, auch wenn ich das System nicht habe – ich muss „nur“ wissen wie die Requests und die Responses ausseen würden.

Script-Deployment ganz einfach

By Henning Eiben in Development, SharePoint 1 Comment

Das schöne am JavaScripting ist ja, dass man eigentlich ganz ohne große IDE auskommt. Eigentlich reicht ein Notepad und ein Browser (zum testen). Damit kann man schon so einiges machen.

Wenn man für SharePoint JavaScripted, dann liegen die JavaScript-Dateien typischerweise in einer Dokumentbibliothek im SharePoint. Nun ist das mit dem Editieren auf einmal doch nicht mehr so ganz einfach. Denn wie kann man am besten JavaScript Dateien in einer Dokumentbibliothek bearbeiten?

Folgende Möglichkeiten stehen dort zur Verfügung:

  • Bearbeiten des JavaScript mit dem SharePoint-Designer. Der SharePoint-Designer hat den Vorteil, dass man halt direkt in der Dokumentbibliothek arbeiten kann. So kann man das JavaScript bearbeiten und direkt speichern und ausprobieren.
  • Öffnen der Dokumentbibliothek im Windows-Explorer. Entweder direkt oder durch mappen des UNC-Pfades auf einen Laufwerksbuchstaben. Leider ist der WebDAV-Zugriff nicht immer ganz schnell, so dass z.B. Notepad++ schon mal pausen einlegt, wenn man zwischen dem Browser und dem Editor wechselt (weil Notepad++ regelmäßig prüft ob sich die Datei im Dateisystem geändert hat).
  • Bearbeiten auf dem lokalen Rechner und anschließendes Hochladen in die Dokumentbibliothek.

Die letzte Möglich ist die naiveste – und auch die nervigste. Denn nach dem Bearbeiten und Speichern muss man immer wieder in die Dokumentbibliothek gehen und die Datei explizit hochladen. Das ist einfach unnötig. Wenn man das doch automatisieren könnte …

Zumindest das manuelle Hochladen von Dateien kann man sich ganz einfach sparen. Mit dem guten alten curl kann man von der Kommandozeile aus HTTP-Zugriffe machen. Das schöne ist – damit kann man z.B. auch HTTP-POSTs durchführen.

curl.exe -T c:\temp\foo.txt --url "http://sp2010.acme.local/Documents/" -u ":" --ntlm

Kann man eine Datei unter den aktuelle Windows-Credentials nach in die Dokumentbibliothek “Documents” SharePoint laden.

Wenn man das nun noch mit dem NppExec-Plugin von Notepad++ kombiniert, dann kann man sich ein folgendes Kommando anlegen:

NPP_SAVE
c:\tools\curl.exe -T "$(FULL_CURRENT_PATH)" --url "http://sp2010.acme.local/Documents/" -u ":" --ntlm

In Notepad++ kann man dann mit F6 den Execute-Dialog aufrufen und das zuletzt verwendete Kommando wird angezeigt und kann direkt ausgeführt werden. Somit wird die aktuelle Datei zuerst gespeichert und dann nach SharePoint geladen.

npp

SharePoint 2013 – Aufgabenliste verschickt keine E-Mails mehr?!

By Christian in Development, Infrastruktur, Neues, SharePoint 0 Comment

Seit SharePoint 2013 fehlt in den Einstellungen einer SharePoint Aufgabenliste die Option „Send e-mail when ownership is assigned? (Yes/No).“. Ich vermute einen Bug in der Oberfläche, der eventuell irgendwann wieder rausgepatchet wird. Nichts desto trotz schreibe ich einen kurze Artikel, wie man dieses Phänomen beheben kann.

Es gibt verschiedene Lösungsansätze, die ich hier kurz darstelle. Eins vorweg: Die Option 3 wäre immer meine erste Wahl!

1. Issue-List beinhaltet die Option noch
Also anstelle der Aufgabenliste das o.g. Template nutzen (vgl. Technet ).

2. Das „alte“ Template verwenden:
Über einen URL-Aufruf kann das „alte“ 2010er Template aufgerufen werden. (vgl. TechNet)
http://siteurl/_layouts/15/new.aspx?FeatureID={00BFEA71-A83E-497E-9BA0-7A5C597D0107}&ListTemplate=107

3. Powershell
Aus meiner Sicht die sauberste und beste der drei Alternativen. Benötigt natürlich Zugriff auf den Server, bzw. Zugriff auf einen Administrator. 😉

$web = Get-SPWeb "http://MeineWebseite"
$list = $web.Lists.TryGetList("Tasks")
$list.EnableAssignToEmail = $true
$list.Update()

Ändern des Edit-Formulars für eine SharePoint Liste

By Henning Eiben in Development, SharePoint 1 Comment

Vor kurzem kam ein Kunde mit einem Problem auf mich zu. Er hatte mit dem SharePoint-Designer ein eigenes Edit-Form für eine Liste erstellt und dieses als Standard-Editor-Formular der Liste zugeordnet. Mit der Zeit wurde die Liste angepasst und es sind neue Feld in die Liste dazugekommen. Leider werden diese neuen Felder von dem angepassten Formular nicht angezeigt.

Nun wollte der Kunde als das Standard-Formular wieder zurücksetzen. Leider wurde in der Zwischenzeit die Verwendung des SharePoint Designers in der Farm deaktiviert. Nun war also die Frage: wie kann ich das Standard Edit-Formular wieder zurücksetzen?

Klare Antwort: PowerShell!

$url = Read-Host "Enter URL" 
$listname = Read-Host "Enter List Name"
$editformurl = Read-Host "Enter Edit Form Url"

$web = Get-SPWeb $url 
$list = $web.Lists[$listname]

$list.DefaultEditFormUrl = $editformurl
$list.update()

So weit, so gut. Aber leider hatte der Kunde keinen Zugriff auf den Server. Somit hilft PowerShell an dieser Stelle leider einmal nicht weiter.

Was bleibt dann noch? JavaScript! Mit dem Client-Object-Model von SharePoint 2010 geht halt doch schon einiges.

<script type="text/javascript">
(function() {
    "use strict";

    var context;
    var list;

    SP.SOD.executeOrDelayUntilScriptLoaded(function () {
        context = new SP.ClientContext.get_current();
        list = context.get_web().get_lists().getByTitle("Test");
        context.load(list);
        context.executeQueryAsync(onSuccessLoadList, onFailure);
    }, "sp.js");

    function onSuccessLoadList() {
        list.set_defaultEditFormUrl("/users/eiben/Lists/Test/NewEditForm.aspx");
        list.update();
        context.executeQueryAsync(onSuccessUpdateList, onFailure);
    }

    function onSuccessUpdateList() {
        alert("done");
    }

    function onFailure(sender, args) {
        SP.UI.Notify.addNotification("Es ist ein Fehler aufgetreten ... " + args.get_message(), true, "", null);
        console.debug(args.get_stackTrace());
    }

})();
</script>

Das mal eben auf der Site z.B. in einem Content-Editor-WebPart einbinden – und voila!

Telefonnummern im SharePoint

By Henning Eiben in Development, SharePoint 0 Comment

SharePoint hilft wo er kann, z.B. bei Links. Wenn ich als Anwender einen “ungültigen” Link in einer SharePoint-Seite einbette, dann entfernt SharePoint den für mich.

Leider ist SharePoint dabei schon mal ein wenig voreilig. Nun wollte ich auf einer Seite im SharePoint einen Link auf eine Telefonnummer wie folgt einbetten:

<a href="tel:+49251123456">+43 (0)251 123456</a>

SharePoint – hilfsbereit wie immer – macht daraus aber:

<a>+49 (0)251 123456</a>

Denn bei dem Protokoll tel: muss es sich um einen Fehler handeln. Das kennt SharePoint (offenbar) nicht!

Was nun? Der Retter kommt in der Form von JavaScript. Ich habe dem Anchor-Tag eine Klasse tel zugewiesen, damit ich die Links auf eine Telefonnummer einfacher finden kann. Somit habe ich nun auf meiner Seite also folgendes eingegeben:

<a class="tel">+49 (0)251 123456</a>

Nun nur noch ein bisserl Code:

jQuery.noConflict();
jQuery(function() {
    jQuery("a.tel").each(function() {
        var number = jQuery(this).text().replace(/\(0\)/g, "");
        jQuery(this).attr("href", "tel:" + number);
    });
});

Und schon werden die Links korrekt eingebettet!

Quick Edit im SharePoint 2013

By Henning Eiben in Development, SharePoint 0 Comment

In SharePoint 2013 hat Microsoft das Quick Edit ja deutlich überarbeitet. Während das Datasheet-Edit bis SharePoint 2010 nur im Internet Explorer möglich war (weil ActiveX Control), geht das nun in jedem Browser.

Ebenfalls neu ist, dass ich direkt aus dem Quick Edit auch neue Spalten anlegen kann.

quick_edit_col

Wenn ich hier also einen neue Spalte NewColumn hinzufüge, dann ist der interne Namen dieser Spalte nicht etwa NewColumn (was ich jetzt naiv erwartet hätte), sondern in diesem Fall war es zz1h.

Das ist gut zu wissen. Besonders wenn man denkt, dass man so mal eben Schnell eine Liste aufbauen kann und dann sich wundert, warum die CAML-Abfrage oder das XSL nicht mehr so ganz wollen.

Silverlight 6 doesn´t matter!?

By Andrej Doms in Development, SharePoint 2 Comments

Ich habe ja bereits vor einigen Wochen auf einen sehr schönen Artikel von Rockford Khotka hingewiesen, auf den mich Oliver Wirkus gebracht hatte. Der Blog ist inzwischen auf meiner Leseliste gelandet. Vor einigen Tagen wurde dort ein weiterer sehr interessanter Post veröffentlicht, der sich mit der Zukunft (oder dem Ende) der .NET und Silverlight Technologien beschäftigt. Eine sehr lesenswerte Meinung und auf jeden Fall ein wertvoller Beitrag zur Diskussion.

Zum Post von Rockford Lhotka…

Windows 8, wohin die Reise geht…

By Andrej Doms in Development, Neues, SharePoint 1 Comment

Die Situation um die Weiterentwicklung der verschiedenen Entwicklungsansätze in Windows 8 ist immer noch nicht hinreichend geklärt. Wohin wird die Reise gehen und mit welcher Technologie bin ich zukunftsfähig. Der IE10 unter Metro wird keine Plugin Schnittstelle besitzen und zumindest bis jetzt beherrscht er auch kein Silverlight. Metro selbst aber ist schon Silverlight capable. Droht dieses Schicksal auch dem Desktop IE10. Liest man die aktuelle ct, dann ist dem so und auch der Desktop IE10 wird keine Plugins mehr unterstützen. Ein mutiger Schritt von Microsoft. Fragt man in die Developer Community rein, so bekommt man zu diesem Thema viele Antworten.

Oliver Wirkus hat auf seinem SharePoint Community Blog gestern auf einen ausgesprochen interessanten Beitrag von Rockford Lhotka hingewiesen, der hoffentlich ein wenig zur Aufklärung beiträgt.

In diesem Zusammenhang kann man ruhig auch mal die Frage stellen, wie es denn an der SharePoint Front weitergeht, denn auch hier muss Microsoft bald mal Farbe bekennen. Für mich ist eigentlich klar, das der Weg HTML5 heißen muss. Das bedeutet aber für uns SharePointer einige große Umbrüche.

No-Code-Ampelfunktion–Teil 3: Erstellen einer kumulierten Sicht auf einer Portalseite

By Patrick in Development, SharePoint 0 Comment

Weiter gehts mit dem 3. und letzten Teil der Blog Serie „No-Code-Ampelfunktion – Bedingte Formatierung, ContentTypes und SharePoint Designer“.

Die Ampelfunktion haben wir in Teil 1 und in Teil 2 erfolgreich erstellt.  Nun ist eine kumulierte Sicht auf einer übergeordneten Portalseite ein leichte Übung. Auch hier helfen uns ganz einfach die vorhandenen Standardmittel weiter: Continue reading