Begonnen hat es ganz einfach. Siehe (hier).
Heute stand am Programm, den TypeScript Code in eine SharePoint hosted App zu transferieren. Wie ich TypeScript in Visual Studio 2013 innerhalb einer SharePoint Hosted App verwenden kann, beschreibe ich später.
Jetzt geht es mal darum, den Json Call auf meine WepApi-Datenbankzugriffs-Schicht in SharePoint abzusetzen. Da wir einen anderen Host als den SharePoint App Host aufrufen, kommt es zu einem CrossDomain Call, der bekanntlich nicht erlaubt ist. Aber genau dafür bietet das SharePoint Client Object Model die Klasse SP.WebProxy.
Also schnell den Code vom Testprojekt auf SharePoint umgeschrieben:
fetchAllItems() { var url: string;
url = "http://localhost:8080/api/GoalSheet/?Quartal=" + this.Quartal();
var request = new SP.WebRequestInfo();
request.set_url(url);
request.set_method('GET'); request.set_headers({ "Accept": "application/json;odata=verbose" });
var context = SP.ClientContext.get_current()
var response = SP.WebProxy.invoke(context, request);
context.executeQueryAsync(
() => { alert('OK'); },
(sender, args) => { alert(args.get_message());
});
//$.getJSON(url,
// it => { // this.GoalSheetItemList(it);
// }
// );
}
Im Code fällt gleich auf, dass ich die URL des WEBAPI Projektes verändert habe. Zuletzt wurde http://localhost:61070/api… verwendet. Diesmal habe ich den Port auf 8080 geändert. Der Versuch mit Port 61070 führte gleich zu einem Fehler: “The scheme-port combination is not supported. Please refer to the WebProxy documentation for the supported set of scheme-port combinations.”
Gesagt, getan: unter http://msdn.microsoft.com/en-us/library/fp179895.aspx habe ich eine Tabelle gefunden, welche Protokoll/Port Kombinationen zulässig sind:
Daher ist Port 8080 geeignet.
Nach dieser Hürde, steht einem neuen Testlauf nichts im Wege und es wird sogar der Success-Handler ausgeführt allerdings nur mit mäßigem Erfolg, wie ein Blick in den Response Inhalt zeigt:
Gleich die nächste Fehlermeldung:
“An exception occurred while processing the request - 'Access to http://localhost:8080/api/GoalSheet/?Quartal=Q1 is denied. SharePoint is currently configured to block intranet calls.'."
Der Hinweis, dass SharePoint derzeit keine Intranet calls zulässt brachte mich dann gleich weiter. Das ist nur ein Setting der SharePoint Farm und kann leicht geändert werden. (wenn man Farm Admin ist 
)
Ist das wieder ein dezenter Hinweis von Microsoft doch die gesamte Entwicklung in Azure auszulagern? Hätte ich mein WebApi Projekt gleich auf Azure gehostet und erst dann weitergearbeitet hätte ich diese Erkenntnisse alle nicht gewinnen können.
aber ok, das Setting lässt sich mit einem PowerShell Script leicht ändern:
$farm=get-spfarm
$farm.properties.disableintranetcalls=$false
$farm.properties.disableintranetcallsfromapps=$false
$farm.Update()
Ab sofort lässt meine Development Farm auch Intranet Calls zu 
Mit dem Debugger, kann ich den Inhalt der Response Variable leicht prüfen und zur großen Freude sind die Datenbankeinträge alle hier:
