Starting script via API call

PowerShell Universal Universal Automation
1 
Product: PowerShell Universal
Version: 2.1.2

I am testing out some scenarios in my lab with Universal Automation. My testing with starting via API call does not seem to be working right, despite following the documented information.

I’ve got a script, which takes 2 mandatory inputs. Problem is that even though I’ve specified these parameters, the script stops to wait for input and shows no indication of parameters when looking at the job page.

Here is a sample of what I’ve been testing to make the call. Script has 2 mandatory parameters, which is what I’m attempting to pass.

$SystemName = [System.Management.Automation.PSSerializer]::Serialize($decomm.System)
    $Domain = [System.Management.Automation.PSSerializer]::Serialize($decomm.Domain)
    
    $JobContext = @{
        JobParameters = @(
            @{Name = "ServerName"; Value = $SystemName},
            @{Name = "Domain"; Value = $Domain}
        )
    } | ConvertTo-Json -Depth 5

    
    Invoke-RestMethod https://wfa.domain.local/api/v1/script/11 -Method POST `
    -Body $JobContext `
    -Headers @{Authorization = "Bearer $Apptoken"} `
    -ContentType 'application/json'
2

Still seeking any input on this particular issue I’m having.

3

You can specify strings via query string so that should simplify it a lot. You can also use the script name rather than the id.

$Parameters = @{
    Uri = "http://localhost:5000/api/v1/script/path/PNP.ps1?Server=tester&Domain=test" 
    Method = "POST"
    Headers = @{Authorization = "Bearer $Apptoken"}
    ContentType = 'applicatio/json'
    Body = '{}'
}

Invoke-RestMethod @Parameters

Working on getting the docs updated for this.

4

got some change in progress at least, except now i get a 401 unauthorized error. This is odd since the same token i had no problem starting the script with the above method in the original post. I can use that token to perform a get on the script path too.

I’ve also tried creating a new token with full Administrator role and got the same result. Any thoughts?

5

I noticed a typo in the content type. Maybe that’s causing it?

6

I didn’t copy your example, just adjusted/rewrote what i already had in vscode testing with.

7

That’s very strange. After looking at the source, both of those are calling the same service in the same way. What happens if you use the query string but the ID rather than the path?

$Parameters = @{
    Uri = "http://localhost:5000/api/v1/script/1?Server=tester&Domain=test" 
    Method = "POST"
    Headers = @{Authorization = "Bearer $Apptoken"}
    ContentType = 'applicatio/json'
    Body = '{}'
}

Invoke-RestMethod @Parameters
8

Looks like that did the trick, changing to the number that corresponds to the script has allowed it to start.

While this will work, I would advise that doing it with the script.ps1 name would be good too, because I noticed the script ID changes if you cleanup old scripts no longer in use.

9

Right. That’s why I suggested it to begin with but it’s unclear to me why it doesn’t work in your environment while it does in mine. It could be some other route conflicting with it. You may be able to crank up the PSU log level and see what the authorization is attempting.

10

I believe this covers the space in the log where I did it using the script name in place of the ID

image
image1462×400 53.6 KB

11

Interesting. I wonder if it’s the spaces. What happens when you do %20 rather than the space? I would think Invoke-RestMethod would handle that…

12

I actually did that already :slight_smile:

So unfortunately not the issue in this case.

13

I guess the other thing you could do is use the HTTP GET to retrieve the script by name and then use the ID to invoke it. Still a bit of a mystery why this happens for you and not me.

14

I’ll investigate using that as a workaround at least for now, thanks for all the help Adam

1 Like