Workspace Management in the Factory Manager - Xyna-Factory/xyna GitHub Wiki
Workspaces and Application Definitions are managed inside the Workspaces section of the Xyna Factory Manager.
The Workspace-specific creation and management actions are described below.
Press the Add Workspace button at the top right and define a name for the new Workspace.
In order to use the new Workspace with SVN Access, choose SVN Repository Access inside the Repository Link drop-down menu and set the parameter for the SVN connection as follows:
- SVN Server Name/IP: Hostname/IP of the SVN server
- Path in SVN: Path pointing to the root directory (must exist) in SVN where the Workspace should check in all changes. Example: trunk/<projectname></projectname>
- Username: SVN Username that should be used by Xyna Factory to check in changes.
- Password: Corresponding password
- Hook Manager Port: Port the SVN Hook Manager listens on (typically 1238)
-
Base directory for branches: Path pointing to the root directory in SVN where branches should be created. Example:
branches/<projectName>
Please note: Right now it is not possible to change the SVN Access parameters from the Xyna Factory Manager afterwards.
To remove all objects inside a certain Workspace (e.g. Services, Data Types, Triggers, Filters and Order Types) open its Workspace Details panel and press the Clear Workspace button. The following dialog request to stop Xyna Orders, which are running in this Workspace. It is possible to exclude several objects from removal by defining a blacklists via Xyna Properties. The according Xyna Properties are already existing and are named with following naming pattern:
xfmg.xfctrl.appmgmt.clearworkingset.blacklist.*.''MyWorkspace''
See the Xyna Properties' particular documentation for further configuration details.
Most of the time the blacklist is used to remove all objects related to a certain Application Definition but keeping all other objects surrounding these objects, e.g. Services for testing those objects. So you can import several versions of an Application one after another to test or develop it.
Select Yes, remove all objects permanently and press the Clear button to finally remove the objects.
Please note: This operation can't be undone.
To remove an existing Workspace open its Workspace Details panel and press the Delete Workspace button. The following dialog request to stop Xyna Orders, which are running in this Workspace. Select Yes, remove this workspace and all its objects and press the Delete button to finally remove this Workspace.
Please note: Similar to clearing a Workspace but without using a blacklist feature this operation removes all objects (e.g. Services, Data Types, Triggers, Filters and Order Types) from this Workspace and can't be undone.
It is possible to import objects of a certain Application into an existing Workspace. The import operation will also create an Application Definition, which contains the imported objects. Again this Application Definition can be used to create a new version of the imported Application (see below).
The import of objects of a certain Application can be done by following these steps:
- Open the Workspace Details
- Press Load Application into Workspace
- Choose an Application for import
- Define a description for the later created Application Definition
- Select Overwrite existing content, if an already existing Application Definition should be replaced
- Press Load to finally import the Application
Alternatively a new Application can be load into a Workspace inside the Applications section.
It is helpfull to create individual development Workspaces for each Application. Then, the Application can be load into dedicated Workspace, separating the Workflows, Datatypes, Trigger, Filter etc. completely from the other development. In case of problems or user mistakes the Workspace can be cleared and the Application reloaded into the Workspace again.
By defining a Requirement towards another Runtime Context the given Workspace is allowed to use the required Runtime Context's content (cf. fig. 1), e.g. XMOM Objects and Order Types. In terms of modeling the Workspace can use all of the XMOM Objects provided by required Runtime Contexts to build new XMOM Objects, e.g. Workflows. The foreign objects are used in a write-protected manner.
The Requirements can be managed by doing the following steps:
- Open the Workspace's Workspace Details panel. The hierarchical structure of the current Requirements are listed inside the Requires box.
- Press the Manage button inside the Requires box to open a new configuration dialog. Disable Show unassigned to show only the required Runtime Contexts. Enable Show implicit to also show the Runtime Contexts that are required implicitly through the Requirements of another required Runtime Context.
- Check or uncheck listed Runtime Contexts to define or undefine a Requirement, respectively
- Press the Apply button to apply all changes
In the Xyna Process Modeller all dependent objects are shown with a lock symbol indicating the read-only character.
Like all objects inside the Workspaces and Applications sections Workspaces supply status information and a lising of current problems. A Workspace can have the following states:
- OK: There are no problems. In particular all Deployment Items are in the Deployment State Deployed and all Application Defintions stand by to build new Applications.
-
WARNING: There are problems with some Deployment Items or other lighter problems. This will be a normal state during development. Use the Deployment Items section of the Xyna Factory Manager to solve those problems.
Please note: If the problems don't affect an included Application Defintion, the Application Definition's status will be OK and it can be used to build new Application anyway. - ERROR: There are critical problems like conflicting objects. A conflict is a situation in which an XMOM Objects or Order Types originates from more than one of the Runtime Contexts in a tree of required Runtime Contexts. You have to solve these conflicts, if you want to use those objects during modeling.
Conflicting objects are a common problem, when two versions of the same Application were imported into this Workspace or during preparing an older Application without Requirements.
Application Definitions mark a subset of their belonging Workspaces' objects to predefine the content of a future Runtme Application. Existing Application Definitions can be found inside the list of Workspaces on the right side of the belonging Workspace.
To create a new Application Definition press the Add Application Defintion button on the right side of a workspace. Keep or change the Workspace via drop-down menu and define a name and documentation for the new Application Definition inside the dialog. Press the Create button to finally create the new Application Definition. The new Application Definition can be found inside the list of Workspaces on the right side of the belonging Workspace.
Analogously Workspace Details the Application Definition provides a status concerning only those Workspace's objects, which are part of the Application Definition.
To remove an existing Application Defintion select it in the list of Workspaces and press the Delete Application Defintion button and confirm the following dialog with Yes.
Figure 3: Show an Application Definition's details (left panel) and change its content (right panel) Open Application Definition Details by selecting an Application Defintion in the list of Workspaces. This panel (cf. left side of fig. 3) provide following information:
- Name: Name of the Application Definition. This is already the name of the future Application.
- Documentation: Documentation about the Application Definition
- Source Version: Version number of an Application, if the Application Definition was created automatically during loading this Application into a Workspace (see above).
- Requires: Shows the required Runtime Contexts.
- Required by: Shows the Runtime Contexts directly or indirectly requiring this Application Definition.
- Content: Shows the current subset of the Workspace's objects, which are part of the Application Definition.
- Issues: Analogously Workspace Details the Application Definition provides monitoring of problems concerning only those Workspace's objects, which are part of the Application Definition.
Like the Workspace itself an Application Definition supports the definition of Requirements. These Requirements will become Requirements of the future Application and can be set analogously the Workspace's Requirements (see above).
The content can be defined by doing the following steps:
- Press Manage in the Content box (cf. left side of fig. 3) to open a new configuration dialog (cf. right side of fig. 3)
- Use the Show unassigned checkbox to toggle between currently assigned and all objects of the workspace.
- Use the Show implicit checkbox to toggle between explicit only and explicit with implicit content definitions. Implicit content definitions point to those objects of the Workspace, which are used and thus implicitly needed by the explicitly defined content definitions.
- Use the Show indirect checkbox to toggle between direct and indirect content definitions. Indirect content definitions point to objects of dependent Workspaces and Applications.
- Check or uncheck listed objects to define or undefine an explicit content definition
- Press the Apply button inside the configuration dialog to apply all changes
Please note: In most cases there are only few objects, that have to be defined as explicit content definition. Depending on the entry points of the Xyna Factory (e.g. Triggers) a single Workflow could meet the requirements, because everything this Workflow can do, e.g. calling other Workflows, is selected as implicit content definition automatically.
To build a new Application from an existing Workspace and Application Definition select the Application Definition in the list of Workspaces and press the Build New Version button. The name of the Application Definition will be used as name of the future Application automatically. Define a version number, which can be any string, and documentation for the new Application inside the dialog. This combination of name and version will uniquely identify the Application build. Press the Create button to finally build the new Application. The new Application can be found inside the Applications section.
Alternatively a new Application can be build inside the Applications section.