Statusing - Classe
Inclut des méthodes pour la gestion des mises à jour de l'état et des affectations dans Project Server.
Hiérarchie d’héritage
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Web.Services.Protocols.WebClientProtocol
System.Web.Services.Protocols.HttpWebClientProtocol
System.Web.Services.Protocols.SoapHttpClientProtocol
WebSvcStatusing.Statusing
Espace de noms : WebSvcStatusing
Assembly : ProjectServerServices (dans ProjectServerServices.dll)
Syntaxe
'Déclaration
<WebServiceBindingAttribute(Name := "StatusingSoap", Namespace := "https://schemas.microsoft.com/office/project/server/webservices/Statusing/")> _
Public Class Statusing _
Inherits SoapHttpClientProtocol
'Utilisation
Dim instance As Statusing
[WebServiceBindingAttribute(Name = "StatusingSoap", Namespace = "https://schemas.microsoft.com/office/project/server/webservices/Statusing/")]
public class Statusing : SoapHttpClientProtocol
Remarques
La classe Statusing est utilisée pour fournir des informations d'état et mettre à jour l'état des affectations. Statusing utilise généralement la sécurité basée sur le contexte utilisateur. Modifications apportées à Project Server 2010 permettent la lecture et de mise à jour des informations d'état sans l'aide de l'emprunt d'identité.
Nouvelles méthodes de Microsoft Project Server 2010 sont les suivantes :
Si l'utilisateur connecté n'est pas la ressource spécifiée, les méthodes ReadStatusForResource et SubmitStatusForResource ne nécessitent pas l'emprunt d'identité.
An application user who has the StatusBrokerPermission global permission can use the UpdateStatus method to update assignment status without impersonation, by including the new ResID attribute of the Assn element in the changeXml parameter. For more information about the ChangeList schema, see Introduction to the ChangeList Schema and Statusing ChangeXML.
Notes
Avec Project Server 2010 Service Pack 1 (SP1), vous pouvez définir l'état chronologique pour les tâches manuelles, à l'aide de la méthode UpdateStatus . Avant SP1, vous pouviez uniquement définir état chronologique pour les tâches planifiées automatiquement.
Les utilisateurs jouent trois rôles dans l'environnement Statusing : Gestionnaire d'état, Propriétaire d'affectationet Les ressources de travail.
Le Gestionnaire d'état est envoyé mises à jour de l'affectation, les nouvelles affectations et les nouvelles tâches pour approbation. Le Gestionnaire d'état est le plus souvent le responsable de projet. Le responsable de projet peut déléguer cette tâche à un autre utilisateur.
Le propriétaire de l'affectation est responsable de l'affectation. Le propriétaire de l'affectation signale un état, met à jour ou délégués comme il convient. Modifications effectuées par le propriétaire de l'affectation doivent être approuvées par le Gestionnaire d'état.
La ressource de travail offre réellement le travail sur cette affectation. La ressource de travail peut être la même que le propriétaire de l'affectation, mais peut être différente ; par exemple, un chef d'équipe peut être un propriétaire de l'affectation, et les membres de son crew serait les ressources de travail.
La classe Statusing tire également parti des ressourcesd'équipe. Une description détaillée des ressources de l'équipe est abordée dans cette section. L'équipe les ressources pouvant être donnée affectations de proxy pour un groupe de ressources de l'équipe. Ressources de travail et les propriétaires des affectations peuvent alors réattribuer vers et à partir de la ressource de l'équipe de travail.
Le cycle de vie d'une affectation peut être source de confusion. Il existe quatre endroits où les affectations peuvent être créées ou stockées : la base de données provisoire, la table de base d'affectation, la table affectation enregistrées et la table de mise à jour.
La figure 1. Cycle de vie de mise à jour de statut
.gif "Gestion des affectations dans les méthodes d’état")
Les affectations sont tout d'abord créées dans le projet d'origine dans la base de données provisoire. Lorsque le projet est publié, l'affectation est copiée dans la table de base d'affectation et une copie identique est copiée dans le tableau affectation enregistrées. Lorsque le propriétaire de l'affectation ou la ressource modifie l'affectation, les modifications sont conservées dans la table d'affectation enregistrées. Lorsque le propriétaire de l'affectation ou la ressource publie les modifications, l'attribution de mise à jour est copiée dans le tableau affectation mis à jour. Les affectations stockées dans la table Affectation mis à jour sont visibles par le Gestionnaire d'état, qui peut accepter ou refuser les modifications. Si le Gestionnaire d'état accepte ces modifications, les modifications sont copiées à la nouvelle copie de travail du projet dans la base de données provisoire. Ces modifications doivent être publiées à partir de la base de données provisoire dans la base de données publiée à mettre à jour la table de base d'attributions avec les nouvelles informations.
Cohérence de thread
Tous les membres statique (Partagé dans Visual Basic)s publics de ce type sont thread-safe. Cela n’est pas garanti pour les membres d’instance.