When publishing applications, one XML file is generated for each page and data group. The application's structure is also defined in an XML file. This approach maintains the separation between the data model and the application and ensures high performance when publishing applications.
If you have created a new application or edited an existing one, you must publish it via the main menu ("File / Publish Application") so that it is available in the portal with all changes. You can find all the information you need—including how to create an entry in the history— here.
Here, the application can be placed within the portal's menu structure.
You can find all the information about this dialog here.
Click "OK" to start using the new application in your browser.
Blocking cohort - Error when publishing applications
The message "An error occurred while publishing the application" may be caused by the following:
-
One or more files are locked by an editor.
-
One or more directories are being prevented from being moved by a virus scanner.
-
Files or directories are prevented from being moved by other programs.
Please make sure that none of these issues apply to your Intrexx server in the portal directory.
Here is an example of a blocking cohort error message:
Failed to end current transaction.
Cause:Cannot complete file transaction. Blocking cohort was de.uplanet.util.transaction.IndirectDirectoryTransaction@37c9e230(internal\tmp\922DB3555CACA7AB9F9D6A2AD0B68CC9CC3846DE-publish-1119770138\internal\application\store\66D4D452039F8C005C9020FA7BF3EE9B857899EC -> .\internal\application\store\66D4D452039F8C005C9020FA7BF3EE9B857899EC).
The error can occur in two situations.
-
Case 1: Another program is already located on one of the affected files or in one of the affected directories.
Examples: text editors, Windows Explorer, command line, etc.
-
Case 2: Another program accesses an affected file or directory at the same time as the file or directory is being published.
Examples: Windows search index, antivirus scanner, backup service, etc.
You can find analysis programs on the Microsoft website:
Process Explorer
https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
Process Monitor
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
First, we recommend testing the app deployment multiple times to rule out the possibility that the files might be temporarily blocked, for example, by a virus scanner or another program. If you are unable to publish the application on a permanent basis, simply closing and restarting all Intrexx Manager instances may help. It might also be helpful to restart the portal or the entire server once. If the data is still blocked after that, it's possible that another program is scanning the directory or keeping it open. You can check this using the programs mentioned above (Process Explorer and Process Monitor).
Test 1 with Process Explorer:
Right-click the program and select "Run as administrator" to run it.
Process Explorer lists programs that access directories or files at runtime. This allows you to check whether a program accesses the directory specified in the error message. In our sample error message, the directory ".\internal\application\store\66D4D452039F8C005C9020FA7BF3EE9B857899EC" is flagged as blocked. In Process Explorer, you can now search for the specified directory GUID (which is also the APP GUID). If another program is actively accessing the directory—which is causing the error—this message will be displayed. In this test, the command line is criticized because we intentionally opened the directory.
Test 2 with Process Monitor:
Right-click the program and select "Run as administrator" to run it.
Process Monitor tracks which files and directories are being blocked or accessed. So if another program accesses the same files or directory while the log is being generated, this can be determined from the logs.
However, it is important to note that only programs that are launched at the time of publication are listed. Therefore, if a program locks or uses a file or directory before it is published, this is not logged.
The log itself grows quite quickly. Therefore, the logging period should be kept as short as possible. The tool also allows you to define a filter. This allows you, for example, to filter by the portal directory. Of course, that depends on the situation.
So the best approach would be to start the log, publish the application immediately, and then, after the error occurs, stop the log right away or save the current state as a CSV file and analyze it using Notepad++, for example. The same applies here as in Test 1. The GUID can be used to determine which program accessed the file or directory. It should be noted, however, that an access does not necessarily mean that it led to an error.