Chacune des entrées de cette librairie indique les informations suivantes:
- Un lien vers la page d'accueil du framework
- Une brève description
- Un lien vers le project github
- Des liens vers des CDN
- Des liens vers des tutoriaux
Juste les petites choses qui m'ont aidé, m'aident et m'aideront
Powershell met à disposition le cmdlet New-WebServiceProxy pour créer un proxy pour appeler vos services WCF. Pour créer le proxy, il suffit de lui donner le WSDL du service a appeler.
Une fois le proxy généré, il suffit d'appeler la méthode correspondant à l'opération. Par exemple :
$proxy = New-WebServiceProxy -uri $WSDLUrl; $res = $proxy.HelloWorld();
Dans le but de faire du monitoring, j'ai écrit un petit script, disponible ci dessous, qui permet, sur base d'un wsdl et du nom de l'opération à appeler, de vérifier que l'opération sur un service s'exécute correctement:
[CmdletBinding(SupportsShouldProcess=$true)]
Param(
[Parameter(Mandatory=$True)][string]$WSDLUrl,
[Parameter(Mandatory=$True)][string]$MethodName
)
Write-Verbose "WSDLUrl=$WSDLUrl"
Write-Verbose "MethodName=$MethodName"
try
{
$proxy = New-WebServiceProxy -uri $WSDLUrl -ErrorAction Stop
if(-not $proxy.$MethodName)
{
Write-Error "Method $MethodName is not declared on service defined at $WSDLUrl"
exit 1;
}
$res = $proxy.$MethodName.Invoke();
}
catch
{
Write-Error $_
exit;
}
if($res)
{
Write-Verbose $res;
}
else
{
Write-Verbose "void";
}
Write-Host "service called"
Cette erreur peut se produire lorsque l'on essaie de récupérer le session id d'une session alors que la réponse au client a déja été envoyée. Le sessionID étant passé par cookies, si on n'en a pas envoyé au client, il n'est dés lors, plus possible de lui renvoyer cet ID.
Un petit workaround pour régler ce problème, consiste à toujours créer un sessionID pour chaque utilisateur. Pour implémenter ce comportement, on peut utiliser l'event Session_Start dans le Global.asax avec le code suivant:
void Session_Start(object sender, EventArgs e)
{
string sessionId = Session.SessionID;
}
La solution que l'on rencontre le plus souvent pour répondre à cette question, consiste à récupérer dans le context quel est le schéma actuel via la fonction sys_context:
sys_context('userenv', 'current_schema')
Cependant, cette méthode ne fonctionnera pas si l'on se trouve dans une procédure d'un package marquée comme devant s'exécuter en utilisant le schéma actuel (c'est à dire de l'appelant) et non le schéma dans lequel se trouve le package(utilisation de "authid current_user" plus d'info ici)
En effectuant, quelques recherches, j'ai trouvé une autre solution (voir ici) qui consiste à analyser la call stack. La première entrée de cette dernière contiendra le nom du schéma et le nom du package qui est appelé(owner.package), il suffira donc d'extraire la première partie (celle juste avant le point) pour connaitre le propriétaire du package.
Une implémentation est proposée sur le site ou j'ai trouvé la réponse à ma question : http://cbohl.blogspot.be/2011/01/determine-owner-of-package.html
function get-string
{
'hello world' -match 'hello'
return $Matches[0];
}
Que ce passera t-il si on appelle cette fonction dans le shell ? En tant que développeur C# je m'attendrai à avoir la valeur "hello" ou une chaîne de caractère.