InTouch Deployment Issue

Unfortunately you are stuck with the orange icon when deploying the application. 
The symbol indicates file transfer in process, and I am assuming it does not complete after a while.

There are some articles on how to resolve this,

If you are unable to undeploy the application to get in to a "starting" position.

then, you need to resolve this, as described here:

https://softwaresupportsp.aveva.com/en-US/knowledge/details/000039412?lang=en_US

Then review the following article from AVEVA to see if you can resolve your application deployment issue.

https://softwaresupportsp.aveva.com/en-US/knowledge/details/000022791?lang=en_US

Regards

Richard

Hi Richard,  

I’ve reviewed the documents, and I noticed that the solution involves running SQL scripts. Could you please confirm which database should be active while executing the script?

Also, will this procedure work for System Platform 2014 R2?

Lastly, if I delete the mentioned folders as per the instructions, will it have any impact on my existing project or deployed applications?

The TSQL script is executed against the Galaxy database, the intention is to manually unflag the object as deploying/deployed, as its stuck in the file transfer process. This is not needed if you are able to undeploy your application using IDE and get back to a normal state with the app undeployed.

It should work with the 2014 version since the gobject table looks the same in this version from the queries perspective. but as the technote explain, ensure proper backups is always good.

3. Delete "C:\Program Files (x86)\ArchestrA\Framework\Bin\<Deployed IntouchViewAppName Folder>
4. C:\Program Files (x86)\ArchestrA\Framework\FileRepository\<Galaxyname>\ObjectFileStorage\<InTouchViewAppName>\Deployed_<nnnn> folder  
5. Clear the contents of C:\ProgramData\ArchestrA\ManagedApp (which is the default local working directory)

The folders in step 3-5 in the technote are not fully described, but to understand what's going on let review what happens when you work with a managed application.

When you create a managed application in IDE, it is initially stored the file system of your GRNode.
In the location, C:\Program Files (x86)\ArchestrA\Framework\FileRepository\<Galaxyname>\ObjectFileStorage\<InTouchViewAppName> with folders for checked in and checked out. to be able cater ongoing development.

These should not be touched and loss of your application could happen if you remove them.

Once you deploy your application to a remote node, there are several things happening, but from an application perspective, the GRNode creates the folder structure to support running the application on the remote node.

But it also creates a copy of the deployed application locally in the above mentioned folder.

This is what's being distributed to the remote node (remember that you can have different 'versions' of the same app on various client nodes depending on when you decide to deploy changes).

So if you have multiple folders, it might mean that you have different versions of your application active.

Once all are up-to date, only one folder should exist.
If you manually delete the Deployed_* folder, a folder containing the (newest version) will be re-created on the next deploy.

On the remote node, folders are created to;

(If you are deploying to a terminal server terminal server environment, where each user gets their own local copy, you might find several folders with you application name if searching).

But initially it creates copies the application to the following folder

C:\Program Files (x86)\ArchestrA\Framework\Bin

The folder C:\ProgramData\ArchestrA\ManagedApp is not populated yet, but will be as soon as you start your application, a folder might exists if you have stared any other application earlier.

Also, when a deploy happens, the GRNode updates the gobject table in the galaxy database, this controls the known state of the deployed object, in your case the application.
If you get stuck at some point of your deployment, witch the GRnode is unable to recover from, you need to manually help it to get back to a normal state, fix the reasons for the failed deploy and try again.

So to clarify the steps in the technote

• Delete "C:\Program Files (x86)\ArchestrA\Framework\Bin\<Deployed IntouchViewAppName Folder>
  (On the remote node)
• C:\Program Files (x86)\ArchestrA\Framework\FileRepository\<Galaxyname>\ObjectFileStorage\<InTouchViewAppName>\Deployed_<nnnn> folder  
  (On The GR)
• Clear the contents of C:\ProgramData\ArchestrA\ManagedApp (which is the default local working directory)
  (On the remote node)

I hope it helps you forward.

Richard

The TSQL script is executed against the Galaxy database, the intention is to manually unflag the object as deploying/deployed, as its stuck in the file transfer process. This is not needed if you are able to undeploy your application using IDE and get back to a normal state with the app undeployed.

It should work with the 2014 version since the gobject table looks the same in this version from the queries perspective. but as the technote explain, ensure proper backups is always good.

3. Delete "C:\Program Files (x86)\ArchestrA\Framework\Bin\<Deployed IntouchViewAppName Folder>
4. C:\Program Files (x86)\ArchestrA\Framework\FileRepository\<Galaxyname>\ObjectFileStorage\<InTouchViewAppName>\Deployed_<nnnn> folder  
5. Clear the contents of C:\ProgramData\ArchestrA\ManagedApp (which is the default local working directory)

The folders in step 3-5 in the technote are not fully described, but to understand what's going on let review what happens when you work with a managed application.

When you create a managed application in IDE, it is initially stored the file system of your GRNode.
In the location, C:\Program Files (x86)\ArchestrA\Framework\FileRepository\<Galaxyname>\ObjectFileStorage\<InTouchViewAppName> with folders for checked in and checked out. to be able cater ongoing development.

These should not be touched and loss of your application could happen if you remove them.

Once you deploy your application to a remote node, there are several things happening, but from an application perspective, the GRNode creates the folder structure to support running the application on the remote node.

But it also creates a copy of the deployed application locally in the above mentioned folder.

This is what's being distributed to the remote node (remember that you can have different 'versions' of the same app on various client nodes depending on when you decide to deploy changes).

So if you have multiple folders, it might mean that you have different versions of your application active.

Once all are up-to date, only one folder should exist.
If you manually delete the Deployed_* folder, a folder containing the (newest version) will be re-created on the next deploy.

On the remote node, folders are created to;

(If you are deploying to a terminal server terminal server environment, where each user gets their own local copy, you might find several folders with you application name if searching).

But initially it creates copies the application to the following folder

C:\Program Files (x86)\ArchestrA\Framework\Bin

The folder C:\ProgramData\ArchestrA\ManagedApp is not populated yet, but will be as soon as you start your application, a folder might exists if you have stared any other application earlier.

Also, when a deploy happens, the GRNode updates the gobject table in the galaxy database, this controls the known state of the deployed object, in your case the application.
If you get stuck at some point of your deployment, witch the GRnode is unable to recover from, you need to manually help it to get back to a normal state, fix the reasons for the failed deploy and try again.

So to clarify the steps in the technote

• Delete "C:\Program Files (x86)\ArchestrA\Framework\Bin\<Deployed IntouchViewAppName Folder>
  (On the remote node)
• C:\Program Files (x86)\ArchestrA\Framework\FileRepository\<Galaxyname>\ObjectFileStorage\<InTouchViewAppName>\Deployed_<nnnn> folder  
  (On The GR)
• Clear the contents of C:\ProgramData\ArchestrA\ManagedApp (which is the default local working directory)
  (On the remote node)

I hope it helps you forward.

Richard