Hi Anoop,

PowerShell is a pipeline based language. So succesfull cmdlet execution in most cases results in returning the (refreshed) object back to the pipeline. This way you can pass it on to the next cmdlet. Quick google, this guy explains it well: https://www.youtube.com/watch?v=QKmyf6c83Rs 

My typical example here would be a combination of an ISHRemote cmdlet that retrieves your Tridion Docs object type and field setup information, to pass it over the pipeline ('|') to a standard PowerShell cmdlet that visualizes it in a nice sortable/filterable grid view.

Get-IshTypeFieldDefinition | Out-GridView

In your sample you pipe to the standard Out-File cmdlet. Now, what will be in your saved file is the (refreshed) object but then serialized to a string. The Get-Help highlights the typical returned OutputType, for  the developers, Set-IShDocumentObj cmdlet specifies this on https://github.com/RWS/ISHRemote/blob/master/Source/ISHRemote/Trisoft.ISHRemote/Cmdlets/DocumentObj/SetIshDocumentObj.cs#L113 

There is no status "during" the cmdlet execution, as it all executes synchronously. To get more inspiration to what is going in, specify parameters -Verbose or even -Debug on your Set-IshDocumentObj request.

If you want to have some inspiration on negative flows, you could have a look at the tests of the Set-IshDocumentObj. Typically it throws (.NET) exceptions on error. See https://github.com/RWS/ISHRemote/blob/master/Source/ISHRemote/Trisoft.ISHRemote/Cmdlets/DocumentObj/SetIshDocumentObj.Tests.ps1#L295

Best wishes,
Dave

Hi Anoop,

PowerShell is a pipeline based language. So succesfull cmdlet execution in most cases results in returning the (refreshed) object back to the pipeline. This way you can pass it on to the next cmdlet. Quick google, this guy explains it well: https://www.youtube.com/watch?v=QKmyf6c83Rs 

My typical example here would be a combination of an ISHRemote cmdlet that retrieves your Tridion Docs object type and field setup information, to pass it over the pipeline ('|') to a standard PowerShell cmdlet that visualizes it in a nice sortable/filterable grid view.

Get-IshTypeFieldDefinition | Out-GridView

In your sample you pipe to the standard Out-File cmdlet. Now, what will be in your saved file is the (refreshed) object but then serialized to a string. The Get-Help highlights the typical returned OutputType, for  the developers, Set-IShDocumentObj cmdlet specifies this on https://github.com/RWS/ISHRemote/blob/master/Source/ISHRemote/Trisoft.ISHRemote/Cmdlets/DocumentObj/SetIshDocumentObj.cs#L113 

There is no status "during" the cmdlet execution, as it all executes synchronously. To get more inspiration to what is going in, specify parameters -Verbose or even -Debug on your Set-IshDocumentObj request.

If you want to have some inspiration on negative flows, you could have a look at the tests of the Set-IshDocumentObj. Typically it throws (.NET) exceptions on error. See https://github.com/RWS/ISHRemote/blob/master/Source/ISHRemote/Trisoft.ISHRemote/Cmdlets/DocumentObj/SetIshDocumentObj.Tests.ps1#L295

Best wishes,
Dave

My Scneario is given below,

• we loop over e.g. 100 localized topics, 1 script execution (the below script)  = 1 topic upload

  • Set-IshDocumentObj

    -IshSession $ishSession `
    -LogicalId $logicalId `
    -Version $version `
    -Lng $lang `
    -Metadata (Set-IshMetadataField -Name "FSTATUS" `
    -Level Lng `
    -ValueType "Element" `
    -Value "VSTATUSTRANSLATIONINREVIEW") `
    -FilePath $filePath |Out-File -FilePath $TestPath

• we then request an output for the publication and language containing the localized topics
• the output succeeds but some topics are still in EN

If Set-IshDocumentObj is really synchronous, why do some topics remain in their original (EN) version?

What can we do in the single-upload script to ensire completion of the upload?

> If Set-IshDocumentObj is really synchronous, why do some topics remain in their original (EN) version?

Could you consider another way of validating the uploaded content besides publishing. So was it indeed uploaded by using

1. Organize Space / Web Client user interface to navigate to the object and check, a preview and properties?
2. Do a Get-IshDocumentObj(Data) cmdlet right after the Set-IshDocumentObj?

You validated with a publishing, where there are more parameters at play. So let's cut the problem in two and check if the uploaded content is really there. Directly and not over an asynchronous publish action.

-Dave