When you publish an application, an XML file is generated for each page and data group. The application structure is also modelled in an XML file. With this approach, the separation of the data model and the application is adhered to, and a high performance when publishing applications is ensured.
If you have created a new application or edited an existing application, you must publish it via the main menu "File / Publish application" so that it is available in the portal with all changes. All information on how you can also create an entry in the history can be found here.
Here the application can be categorized in the menu structure of the portal.
All information on this dialog can be found here.
Click on "OK" to use the new application in the browser.
Blocking cohort - Error when publishing applications
The message "An error occurred while publishing the application" can have the following causes:
-
One or more files are blocked by an editor.
-
One or more directories are 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 causes 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 be caused by two situations.
-
Case 1: Another program is already installed on one of the affected files or an affected directory.
Examples: Editors, Windows Explorer, command line, etc.
-
Case 2: Another program accesses an affected file or directory at the same time during publishing.
Examples: Windows search index, virus scanner, backup service, etc.
You can find programs for analysis at Microsoft:
Process Explorer
https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
Process Monitor
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
On the one hand, we recommend testing the publication of the application several times in order to be able to rule out a temporary blocking of the files, e.g. by a virus scanner or another program. If it is not possible to publish the application permanently, it may help to close and restart all Intrexx Managers. It may also be helpful to restart the portal or the entire server once. If the data is still blocked afterwards, it is possible that another program is scanning the directory or keeping it open. This can be checked with the programs mentioned above (Process Explorer and Process Monitor).
Test 1 with Process Explorer:
The program must be executed by right-clicking "Run as administrator".
The Process Explorer outputs programs that access directories or files at runtime. This allows you to check whether a program is accessing the directory specified in the error. In our example error message, the directory ".\internal\application\store\66D4D452039F8C005C9020FA7BF3EE9B857899EC" is reported as blocked. You can now search for the directory GUID (which is also the APP GUID) in the Process Explorer. If another program is actively accessing the directory, which causes the error, this is displayed. Here in our test, the command line is criticized because we deliberately opened the directory.
Test 2 with Process Monitor:
The program must be executed by right-clicking "Run as administrator".
Process Monitor records the blocking or use of files and directories. This means that if another program accesses the same files or the same directory during publishing, this can be seen in the recordings.
However, it is important to know that only programs that are started at the time of publishing are recorded. If a program blocks or uses a file or directory before publishing, this is not logged.
The log itself grows quite quickly. The logging period should therefore be kept as short as possible. The tool also offers the option of defining a filter. This allows you to filter on the portal directory, for example. This of course depends on the situation.
It would therefore be best to start the log, publish the application directly and close the log again immediately after the error or save the current status as a CSV and analyze it with Notepad++, for example. The same applies here as in test 1. The GUID can be used to determine which program has accessed the file or directory. However, it should be noted that access does not necessarily mean that this has led to an error.
Send us an e-mail