Aufrufen von Webdiensten aus SharePoint-Workflows
Mithilfe des SharePoint-Add-In-Modells können Sie Workflows erstellen und bereitstellen, die entweder im Add-In-Web oder im Hostweb ausgeführt werden. Diese Workflows können mit den remote gehosteten Teilen von vom Anbieter gehosteten Add-Ins interagieren.
Die Workflows können auch Remote-Webdienste aufrufen, die wichtige Geschäftsdaten enthalten, und zwar auf zwei Arten:
Durch Übergeben von Abfrageinformationen an den remote gehosteten Teil des Add-Ins. Die Remote-Webanwendung ruft dann den Webdienst auf und übergibt die Informationen zurück an SharePoint.
Durch Abfragen des Webdiensts unter Verwendung des SharePoint-Webproxys. Der Workflow übergibt die Ergebnisse der Abfrage an den remote gehosteten Teil des Add-Ins, der dann die Informationen an SharePoint übergibt.
Die vom Webdienst abgerufenen Informationen können in SharePoint-Listen gespeichert werden.
In diesem Artikel werden drei Codebeispiele erläutert, um zu zeigen, wie Webdienste aus Workflows aufgerufen werden können. Siehe hierzu die nachstehende Tabelle. In den ersten beiden Beispielen werden die Workflows und Listen im Add-In-Web bereitgestellt, wenn das Add-In installiert wird. Das letzte Beispiel enthält das grundlegende Gerüst eines Workflows sowie Anweisungen zu dessen Bereitstellung im Hostweb und seiner Zuordnung zu einer Liste im Hostweb.
Workflowaufgaben und entsprechende Beispiele
| Aufgabe | Beispiel |
|---|---|
| Aufrufen benutzerdefinierter Webdienste aus einem Workflow | Workflow.CallCustomService |
| Aufrufen eines benutzerdefinierten Webdienstes aus einem Workflow und Aktualisierung von SharePoint über den SharePoint-Webproxy | Workflow.CallServiceUpdateSPViaProxy |
| Einen Workflow dem Hostweb zuordnen | Workflow.AssociateToHostWeb |
Aufrufen benutzerdefinierter Webdienste aus einem Workflow
Im Workflow.CallCustomService-Beispiel wird gezeigt, wie Sie einen Workflow erstellen, der einen benutzerdefinierten Webdienst aufruft, der SharePoint-Listendaten aktualisiert. Außerdem wird gezeigt, wie Sie ein vom Anbieter gehostetes Add-In so entwerfen, dass es einen Webdienst über die remote gehostete Webanwendung abfragt, die mit dem Add-In bereitgestellt wird. Dieses Beispiel ist nützlich, wenn alle Interaktionen mit dem Webdienst vom remote gehosteten Teil Ihres vom Anbieter gehosteten Add-Ins verarbeitet werden sollen.
Bei diesem Beispiel wird ein Workflow von einer Remote-Webanwendung aus gestartet. Dieser Workflow übergibt vom Benutzer übermittelte Abfrageinformationen an die Remote-Webanwendung, die diese Informationen dann verwendet, um eine Abfrage an den Northwind OData-Webdienst zu erstellen. Die Abfrage gibt die Produktanbieter für ein bestimmtes Land zurück. Nachdem sie diese Informationen erhalten hat, aktualisiert die Remote-Webanwendung eine Produktanbieterliste, die vom Add-In im Add-In-Web bereitgestellt wurde.
Hinweis
Die Workflow.CallCustomService-Beispielseite enthält Anweisungen zum Bereitstellen dieses Add-Ins. Sie können für das Bereitstellen und Testen auch das F5-Debugging in Visual Studio verwenden. Befolgen Sie hierzu die Anweisungen im Blogbeitrag Debuggen von SharePoint 2013-Workflows mit Visual Studio 2013.
Die Startseite des Workflow.CallCustomService-Beispiel-Add-Ins umfasst ein Dropdownmenü zur Auswahl eines Landes, für das eine Produktanbieterliste erstellt werden soll.
Über die Schaltfläche Create auf dem Bildschirm wird eine Create-Methode in der Datei "Controllers\PartSuppliersController.cs" aufgerufen, die einen neuen Eintrag in der Liste der Teileanbieter im Add-In-Web erstellt. Die Create-Methode ruft dann die Add-Methode auf, die in der Datei "Services\PartSuppliersService.cs" definiert ist. Die Sequenz wird in den folgenden beiden Codebeispielen gezeigt.
Create-Methode
public ActionResult Create(string country, string spHostUrl)
{
var spContext = SharePointContextProvider.Current.GetSharePointContext(HttpContext);
using (var clientContext = spContext.CreateUserClientContextForSPAppWeb())
{
var service = new PartSuppliersService(clientContext);
var id = service.GetIdByCountry(country);
if (id == null)
{
id = service.Add(country);
TempData["Message"] = "Part Supplier Successfully Created!";
}
else
TempData["ErrorMessage"] = string.Format("Failed to Create The Part Supplier: There's already a Part Supplier who's country is {0}.", country);
return RedirectToAction("Details", new { id = id.Value, SPHostUrl = spHostUrl });
}
}
Add-Methode
public int Add(string country)
{
var item = list.AddItem(new ListItemCreationInformation());
item["Country"] = country;
item.Update();
clientContext.ExecuteQuery();
return item.Id;
}
Nach dem Erstellen dieses neuen Listenelements wird im Add-In die Schaltfläche Start Workflow angezeigt, über die der Genehmigungsworkflow gestartet wird.
Wenn Sie die Schaltfläche Start Workflow anklicken, wird die StartWorkflow-Methode ausgelöst, die in der Datei "Controllers\PartSuppliersController.cs" definiert ist. Diese Methode verpackt die Add-In-Web-URL, die Webdienst-URL (für Ihre remote gehostete Webanwendung, nicht für den Northwind-Webdienst) und die Kontexttokenwerte, und übergibt sie an die StartWorkflow-Methode. Die PartSuppliersService-Methode benötigt das Kontexttoken, um mit SharePoint zu interagieren.
public ActionResult StartWorkflow(int id, Guid workflowSubscriptionId, string spHostUrl)
{
var spContext = SharePointContextProvider.Current.GetSharePointContext(HttpContext) as SharePointAcsContext;
var webServiceUrl = Url.RouteUrl("DefaultApi", new { httproute = "", controller = "Data" }, Request.Url.Scheme);
var payload = new Dictionary<string, object>
{
{ "appWebUrl", spContext.SPAppWebUrl.ToString() },
{ "webServiceUrl", webServiceUrl },
{ "contextToken", spContext.ContextToken }
};
using (var clientContext = spContext.CreateUserClientContextForSPAppWeb())
{
var service = new PartSuppliersService(clientContext);
service.StartWorkflow(workflowSubscriptionId, id, payload);
}
TempData["Message"] = "Workflow Successfully Started!";
return RedirectToAction("Details", new { id = id, SPHostUrl = spHostUrl });
}
Die StartWorkflow-Methode erstellt dann eine Workflowinstanz und übergibt die drei Werte (appWebUrl, webServiceUrl, contextToken), die in der Nutzlastvariablen enthalten sind, an den Workflow.
{
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var subscriptionService = workflowServicesManager.GetWorkflowSubscriptionService();
var subscription = subscriptionService.GetSubscription(subscriptionId);
var instanceService = workflowServicesManager.GetWorkflowInstanceService();
instanceService.StartWorkflowOnListItem(subscription, itemId, payload);
clientContext.ExecuteQuery();
}
Nachdem der Workflow gestartet wurde, wird eine POST HTTP-Anforderung an die remote gehostete Webanwendung gesendet. Diese Anforderung weist die Webanwendung an, die Anbieterliste mit den Anbietern für das Land zu aktualisieren, das der Benutzer gerade hinzugefügt hat. Die Datei "Controllers\DataController.cs" enthält eine POST-Methode, die den Inhalt dieser Anforderung empfängt.
public void Post([FromBody]string country)
{
var supplierNames = GetSupplierNames(country);
UpdateSuppliers(country, supplierNames);
}
Die GetSupplierNames-Methode (in der Datei "Controllers\DataController.cs") erstellt und führt eine LINQ-Abfrage für den Northwind OData-Webdienst für alle Lieferanten aus, die dem ausgewählten Land zugeordnet sind.
private string[] GetSupplierNames(string country)
{
Uri uri = new Uri("http://services.odata.org/V3/Northwind/Northwind.svc");
var entities = new NorthwindEntities(uri);
var names = entities.Suppliers
.Where(s => s.Country == country)
.AsEnumerable()
.Select(s => s.CompanyName)
.ToArray();
return names;
}
Die UpdateSuppliers-Methode aktualisiert dann das Feld Suppliers des neu hinzugefügten Listenelements.
private void UpdateSuppliers(string country, string[] supplierNames)
{
var request = HttpContext.Current.Request;
var authority = request.Url.Authority;
var spAppWebUrl = request.Headers["SPAppWebUrl"];
var contextToken = request.Headers["SPContextToken"];
using (var clientContext = TokenHelper.GetClientContextWithContextToken(
spAppWebUrl, contextToken, authority))
{
var service = new PartSuppliersService(clientContext);
service.UpdateSuppliers(country, supplierNames);
}
}
Wenn Sie sich die Entwurfsansicht der Datei "workflow.xaml" im Verzeichnis "Approve Suppliers" des Add-In-Projekts ansehen, sehen Sie (durch Auswählen der Registerkarte Arguments unten links in der Entwurfsansicht), dass der Workflow die drei Werte in der an ihn übergebenen Nutzlastvariablen als Workflowargumente speichert.
Die HttpSend--Aktivität erfolgt vor der Workflowgenehmigung. Diese Aktivität sendet die POST--Abfrage an Ihre Remote-Webanwendung, die den Aufruf des Northwind-Webdiensts und dann die Aktualisierung des Listenelements (mit der Lieferantenliste) auslöst. Diese Aktivität ist so konfiguriert, dass die Anforderung an den webServiceUrl-Wert gesendet wird, der als Workflowargument übergeben wurde.
Die POST-Anforderung übergibt auch den Länderwert, der in dem Listenelement angegeben ist, an dem der Workflow arbeitet.
Der Workflow sendet die Werte für "appWebUrl" und "contextToken" über die Anforderungsheader an die Webanwendung. Die Header legen auch die Inhaltstypen zum Senden und Annehmen von Anforderungen fest.
Wenn der Workflow genehmigt wird, wird der Wert des Felds isApproved des Listenelements in true geändert.
Aufrufen eines benutzerdefinierten Webdienstes aus einem Workflow und Aktualisierung von SharePoint über den SharePoint-Webproxy
Anhand des Workflow.CallServiceUpdateSPViaProxy-Beispiels wird gezeigt, wie Sie ein vom Anbieter gehostetes Add-In entwerfen können, um einen Webdienst abzufragen und die erhaltenen Informationen dann über den SharePoint-Webproxy an eine SharePoint-Liste zu übergeben.
Das Beispiel umfasst eine Aufgabe, die nützlich ist, wenn Sie alle Interaktionen mit einem Webdienst kapseln möchten, sodass sie direkt vom Workflow verarbeitet werden. Die Verwendung des Webproxys erleichtert das Aktualisieren der Logik der Remote-Webanwendung, ohne die Workflowinstanz aktualisieren zu müssen. Wenn Sie den Proxy nicht verwenden und die Logik in Ihrer Webanwendung aktualisieren müssen, müssen Sie die vorhandenen Workflowinstanzen entfernen, und das Add-In dann erneut bereitstellen. Aus diesem Grund wird dieser Aufbau empfohlen, wenn ein Remote-Webdienst aufgerufen werden muss.
Hinweis
Die Workflow.CallServiceUpdateSPViaProxy-Beispielseite enthält Anweisungen zum Bereitstellen dieses Add-Ins. Sie können für das Bereitstellen und Testen des Add-Ins auch das F5-Debugging in Visual Studio verwenden. Befolgen Sie hierzu die Anweisungen im Blogbeitrag Debuggen von SharePoint 2013-Workflows mit Visual Studio 2013.
Bei diesem Beispiel wird ein Workflow aus einer Remote-Webanwendung gestartet. Dieser Workflow übergibt vom Benutzer übermittelte Abfrageinformationen an den Northwind OData-Webdienst. Die Abfrage gibt die Produktanbieter für ein bestimmtes Land zurück. Nachdem die Webdienstantwort empfangen wurde, übergibt der Workflow die Informationen aus der Antwort an die Remote-Webanwendung. Die Remote-Webanwendung aktualisiert dann eine Produktanbieterliste, die vom Add-In im Add-In-Web bereitgestellt wurde.
Wenn Sie das CallServiceUpdateSPViaProxy-Beispiel-Add-In starten, umfasst die Startseite ein Dropdownmenü zur Auswahl eines Landes, für das eine Produktanbieterliste erstellt werden soll.
Über die Schaltfläche Create wird eine Methode in der Datei "Controllers\PartSuppliersController.cs" aufgerufen, die einen neuen Eintrag in der Liste der Teileanbieter im Add-In-Web erstellt. Die Create-Methode in dieser Datei ruft dann die Add-Methode auf, die in der Datei "Services\PartSuppliersService.cs" definiert ist. Beides sehen Sie in den folgenden beiden Codebeispielen.
Create-Methode
public ActionResult Create(string country, string spHostUrl)
{
var spContext = SharePointContextProvider.Current.GetSharePointContext(HttpContext);
using (var clientContext = spContext.CreateUserClientContextForSPAppWeb())
{
var service = new PartSuppliersService(clientContext);
var id = service.GetIdByCountry(country);
if (id == null)
{
id = service.Add(country);
TempData["Message"] = "Part Supplier Successfully Created!";
}
else
TempData["ErrorMessage"] = string.Format("Failed to Create The Part Supplier: There's already a Part Supplier who's country is {0}.", country);
return RedirectToAction("Details", new { id = id.Value, SPHostUrl = spHostUrl });
}
}
Add-Methode
public int Add(string country)
{
var item = list.AddItem(new ListItemCreationInformation());
item["Country"] = country;
item.Update();
clientContext.ExecuteQuery();
return item.Id;
}
Nach dem Erstellen dieses neuen Listenelements wird im Add-In die Schaltfläche Start Workflow angezeigt, über die der Genehmigungsworkflow gestartet wird.
Wenn Sie die Schaltfläche Start Workflow anklicken, wird die StartWorkflow-Methode in der Datei "Controllers\PartSuppliersController.cs" ausgelöst. Diese Methode verpackt die Add-In-Web-URL und die Webdienst-URL (für Ihre remote gehostete Webanwendung, nicht für den Northwind-Webdienst) und übergibt sie an die StartWorkflow-Methode in der Services\PartSuppliersService.cs-Datei. Der Workflow kommuniziert über den Webproxy mit der Remote-Webanwendung, und der Webproxy fügt das Zugriffstoken in einem Anforderungsheader hinzu. Aus diesem Grund übergibt der Workflow in diesem Beispiel kein Kontexttoken an die StartWorkflow-Methode. Den Code sehen Sie im folgenden Beispiel.
public ActionResult StartWorkflow(int id, Guid workflowSubscriptionId, string spHostUrl)
{
var spContext = SharePointContextProvider.Current.GetSharePointContext(HttpContext);
var webServiceUrl = Url.RouteUrl("DefaultApi", new { httproute = "", controller = "Data" }, Request.Url.Scheme);
var payload = new Dictionary<string, object>
{
{ "appWebUrl", spContext.SPAppWebUrl.ToString() },
{ "webServiceUrl", webServiceUrl }
};
using (var clientContext = spContext.CreateUserClientContextForSPAppWeb())
{
var service = new PartSuppliersService(clientContext);
service.StartWorkflow(workflowSubscriptionId, id, payload);
}
TempData["Message"] = "Workflow Successfully Started!";
return RedirectToAction("Details", new { id = id, SPHostUrl = spHostUrl });
}
Die StartWorkflow-Methode erstellt eine Workflowinstanz und übergibt die beiden Werte (appWebUrl und webServiceUrl), die in der Nutzlastvariablen enthalten sind, an den Workflow.
public void StartWorkflow(Guid subscriptionId, int itemId, Dictionary<string, object> payload)
{
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var subscriptionService = workflowServicesManager.GetWorkflowSubscriptionService();
var subscription = subscriptionService.GetSubscription(subscriptionId);
var instanceService = workflowServicesManager.GetWorkflowInstanceService();
instanceService.StartWorkflowOnListItem(subscription, itemId, payload);
clientContext.ExecuteQuery();
}
Nachdem der Workflow gestartet wurde und bevor er genehmigt wird, sendet er eine Abfrage an den Northwind-Webdienst, um die Lieferantenliste für das ausgewählte Land abzurufen. Dazu wird eine HTTPSend--Aktivität verwendet, die eine OData-Abfrage an diesen Endpunkt sendet: "http://services.odata.org/V3/Northwind/Northwind.svc/Suppliers/?$filter=Country eq '" + country.Replace("'", "''") + "'&$select=CompanyName".
Die HttpSend-Aktivität sollte als GET-Anforderung mit einem Accept-Header konfiguriert werden, in dem JSON ohne Metadaten angegeben ist: application/json;odata=nometadata.
Wenn der Benutzer z. B. Kanada für das neue Lieferantenlistenelement ausgewählt hat, wird die Antwort im JSON-Format wie im folgenden Beispiel aussehen.
{
value: [
{
CompanyName: "Ma Maison"
},
{
CompanyName: "Forêts d'érables"
}
]
}
Nachdem der Workflow gestartet wurde, sendet er über den Proxy eine POST HTTP-Anforderung, die die Lieferantenliste für die remote gehostete Webanwendung enthält. Dies erfolgt über eine HttpSend--Aktivität, die die Webproxy-URL abfragt: appWebUrl + "/_api/SP.WebProxy.invoke".
Der Workflow übergibt dann die Lieferantenliste, die er vom Northwind-Dienst erhalten hat, indem er eine benutzerdefinierte Dienstnutzlast erstellt und übergibt. Die Create Custom Service Payload-Aktivitätseigenschaften enthalten die Lieferantenliste und die ID für das Lieferantenland.
Die Aktivität Create WebProxy Payload erstellt eine Nutzlast, die den Inhalt dieser Nutzlast an die Webproxy-URL übergibt.
In den Eigenschaften für die WebProxy Payload-Aktivität sind die Add-In-Web-URL, Länge und Typ des POST-Anforderungsinhalts und der Anforderungsannahmetyp über Anforderungsheader angegeben.
Nachdem der Workflow die Nutzlast und die Anforderung erstellt hat, übergibt er die Anforderung mithilfe einer HttpSend-Aktivität , die als POST-Anforderung an die Webproxy-URL konfiguriert ist, an den Webproxy. In den Anforderungsheadern sind OData im JSON-Format im Content-Type- und Accept-Header angegeben.
Die Post-Methode in der Datei Controllers\DataController.cs akzeptiert den Inhalt der Anforderung, die der Workflow über den Webproxy sendet. Die Post-Methode im vorherigen Beispiel hat eine Methode zum Abrufen der Anbieterliste aus Northwind sowie eine Methode zum Aktualisieren der entsprechenden SharePoint-Anbieterliste aufgerufen.
Da der Workflow in diesem Beispiel bereits den Northwind-Dienst abgefragt hat, muss diese Version der Methode nur die SharePoint-Liste aktualisieren. Außerdem werden die Add-In-Web-URL und das Zugriffstoken (das vom Webproxy übergeben wird) an die UpdateSuppliers-Methode in der Datei "Services\PartSuppliersService.cs" übergeben, wie im folgenden Codebeispiel gezeigt.
public void Post(UpdatePartSupplierModel model)
{
var request = HttpContext.Current.Request;
var authority = request.Url.Authority;
var spAppWebUrl = request.Headers["SPAppWebUrl"];
var accessToken = request.Headers["X-SP-AccessToken"];
using (var clientContext = TokenHelper.GetClientContextWithContextToken(spAppWebUrl, accessToken, authority))
{
var service = new PartSuppliersService(clientContext);
service.UpdateSuppliers(model.Id, model.Suppliers.Select(s => s.CompanyName));
}
}
Die UpdateSuppliers-Methode in der Datei "PartSuppliers.cs" aktualisiert das Feld Suppliers des neu erstellten Listenelements.
public void UpdateSuppliers(int id, IEnumerable<string> supplierNames)
{
var item = list.GetItemById(id);
clientContext.Load(item);
clientContext.ExecuteQuery();
string commaSeparatedList = String.Join(",", supplierNames);
item["Suppliers"] = commaSeparatedList;
item.Update();
clientContext.ExecuteQuery();
}
Wenn der Workflow genehmigt wird, wird der Wert des Felds isApproved des Listenelements in true geändert.
Einen Workflow dem Hostweb zuordnen
Anhand des Beispiels "Workflow.AssociateToHostWeb" wird gezeigt, wie Sie einen Workflow im Hostweb bereitstellen und mithilfe von Tools in Visual Studio einer Liste im Hostweb zuordnen. In den Anweisungen für dieses Beispiel wird erläutert, wie Sie einen Workflow in Visual Studio erstellen, ihn im Hostweb bereitstellen und einer Liste im Hostweb zuordnen.
Das Beispiel umfasst einen einfachen Workflow, der einer beliebigen Liste zugeordnet werden kann. In den Anweisungen zum Bereitstellen dieses Workflows wird erklärt, wie Sie die aktuellen Einschränkungen der Visual Studio-Workflowtools umgehen können, indem Sie das Add-In packen, es öffnen und eine Konfigurationsdatei bearbeiten, und es dann manuell wieder packen, bevor Sie es im Hostweb bereitstellen.
Wenn Sie dieses Projekt in Visual Studio öffnen, werden Sie sehen, dass es sich um einen einfachen, generischen Workflow handelt, der für den Einsatz mit einer beliebigen SharePoint-Liste konzipiert ist. Abgesehen von der Workflowaufgabenliste wird keine Liste bereitgestellt, dem er zugeordnet werden kann.
Hinweis
Sie können die in diesem Beispiel gezeigte Aufgabe nicht unter Verwendung von Visual Studio 2013 ausführen. Dieses Beispiel bietet eine nützliche Problemumgehung. Wenn die Visual Studio-Tools in Zukunft aktualisiert werden, müssen Sie diese Problemumgehung möglicherweise nicht mehr verwenden.
Bereitstellen eines Workflows im Hostweb
Öffnen Sie das Kontextmenü (Rechtsklick) für das Add-In-Projekt "Workflow.AssociateToHostWeb" im Projekt-Explorer, und wählen Sie Publish aus. Es wird ein Fenster angezeigt, das eine SchaltflächePackage the app enthält.
Wenn Sie App packen auswählen, erstellt Visual Studio eine Workflow.AssociateToHostWeb.app Datei im
bin\Debug\app.publish\1.0.0.0Verzeichnis Ihrer Projektmappe. Bei dieser APP-Datei handelt es sich um einen ZIP-Dateityp.Extrahieren Sie den Inhalt der Datei, nachdem Sie die Dateierweiterung in ZIP geändert haben.
Suchen und öffnen Sie in dem extrahierten Verzeichnis die XML-Datei "WorkflowManifest.xml". Die Datei ist leer.
Fügen Sie der Datei das folgende XML-Fragment hinzu, und speichern Sie sie dann.
<SPIntegratedWorkflow xmlns="http://schemas.microsoft.com/sharepoint/2014/app/integratedworkflow"> <IntegratedApp>true</IntegratedApp> </SPIntegratedWorkflow>Wählen Sie alle Dateien im extrahierten Ordner aus, öffnen Sie dann das Kontextmenü (Rechtsklick) für die Dateien, und wählen Sie An>Compressed (zipped) folder aus.
Ändern Sie bei der soeben erstellten ZIP-Datei die Dateierweiterung in ".app". Sie sollten nun über ein neues "Workflow.AssociateToHostWeb.app"-Paket verfügen, das die aktualisierte Datei "WorkflowManifest.xml" enthält.
Fügen Sie das Add-In Ihrem App-Katalog hinzu.
Installieren Sie das Add-In auf Ihrer Hostwebsite.
Wechseln Sie zu einer Liste auf Ihrer Hostwebsite, und wählen Sie oben links auf der Seite die Bearbeitungsoption Liste aus. Ein Dropdownmenü mit Workfloweinstellungen wird angezeigt.
Wählen Sie im Dropdownmenü Add a Workflow aus.
Nun wird eine Auswahloption ähnlich wie in der folgenden Abbildung angezeigt. Wählen Sie das Workflow.AssociateToHostWeb-Add-In aus der Liste der verfügbaren Optionen aus.
Sie haben den Workflow nun im Hostweb bereitgestellt und ihn einer Liste im Hostweb zugeordnet. Sie können einen Workflow manuell auslösen oder ihn in Visual Studio so aktualisieren, dass er auf andere Weise ausgelöst wird.