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. Click here for more information about creating an entry in the history when publishing applications.
Here the application can be categorized in the menu structure of the portal.
Click here for more information on this dialog.
When you click on "OK", the new application can be used 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 being locked by an editor.
-
A virus scanner that prevents one or more directories being moved.
-
Other programs are preventing files or directories from being moved.
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 is simultaneously accessing an affected file or directory during publishing.
Examples: Windows search index, virus scanner, backup service, etc.
You can find analysis programs 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
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 continues to be impossible to publish the application, 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 after this, 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, causing the error, this is displayed. Here in our test, the command line is pointed out as being a problem 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 during the time publishing is being executed are recorded. If a program blocks or uses a file or directory before publishing, this is not logged.
The log itself becomes large quite quickly. Consequently, the logging period should be kept as short as possible. The tool also offers the option of defining a filter. This allows you to filter for the portal directory, for example. Of course, this depends on the situation.
It would be best to start the log, publish the application right away 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 an access does not necessarily mean that this is what caused the error.
Email us