Service Group
A Service Group is a clustering of functionally associated Coded Services. In contrast to a Data Type containing Instance Services, a Service Group only contains Coded Services.
All Coded Services contained in one Service Group will be implemented within the same Eclipse project when downloading as Template.
Create a new Service Group in Xyna Process Modeller using the New Document symbol 
in the left icon bar and select Service Group. The details of new tab contains the newly created Service Group with its Label, Path and the section for its grouped Coded Services.
The location of the Service Group is defined by its Label as well as its Path (the structure Department.Section.FunctionGroup is only used for orientation). The given label should be user-friendly and functional. The Name of the Service Group is automatically derived from the label. It is possible to use libraries within the implementation of the Service Group, which can be uploaded in the section (Java Libraries and Java Shared Libraries) (see below).
New Coded Services are added to a Service Group by clicking the + symbol next to the header labeled Services on the left. To specify a Label, Input and Output Parameters as well as thrown Exception Types, simply click on the newly created Coded Service.
Please note: Throwing Exceptions should be modeled for every single Coded Service before downloading a Java Template to implement the Service (see below). Only then all Java-based method bodies of the downloaded Template have the appropriate throws declarations.
Please note: It is not possible to assign Workflows as Service to a Service Group.
To remove a Coded Service, click the bin-symbol next to it or use the <kbd>Del</kbd> key on any selected Coded Service.
Using the Deployment symbol 
in the left icon bar (<kbd>Ctrl+Shift+D</kbd>), the Service Group is saved and made available. During this process all Services contained in the Service Group are getting deployed. If a Deployment of a contained Service fails, a corresponding error message is displayed.
In order to implement the modeled Services of a Service Group, a Java Template can be generated and downloaded using the Download Template symbol 
in the left icon bar. The created zip file in this process (wait for the download, since the process might take up to a minute) contains a Java Project ready to be edited and implemented in an external Integrated development environment (IDE) e.g. Eclipse (Import Java Template into Eclipse).
The Template contains predefined Java classes, which already contain all signatures of the existing Services in the Service Group.
Service implementations usually have dependencies to other Data Types e.g. Input and Output Parameters. These dependencies are recognized automatically by the server if they occur directly in the method body. Other dependencies like e.g. Service internal read Xyna Properties or method internal Orders are not recognized automatically and must be added manually to the XML definition file of the Service Group.
To manually add additional dependencies, proceed as follows:
The generated zip file, downloaded as Java Template for a Service Group, also contains the XML definition of the Service Group (in the subfolder xmldefinition). Insert the following section into the XML file: <syntaxhighlight lang="xml"> <DataType ...> <Service ...> <Meta> <AdditionalDependencies> <XynaProperty>usedPropertyName</xynaproperty> <Datatype>anotherPath.anotherType</datatype> </additionaldependencies> </meta> ... </service> </datatype> </syntaxhighlight> The identifiers (XynaProperty and Data Type in the example above) indicate for which kind of element the dependency will be specified. Data Types have to be specified using their full path e.g. xprv.XCtx.Subscriber.SubscriberID.
The following element types are possible:
- Data Type
- ExceptionType
- Workflow
- Trigger
- Filter
- SharedLib
- Ordertype
- XynaProperty
Please note: After transferring the XML file to the server, a client-triggered Deployment can still overwrite the modified XML file on the server, if the client has opened the Service Group before the transfer of the XML file was complete.
For the Coded Service to run the appropriate code during runtime, the created implementation JAR file has to be added to the Service Group. This can be done using the following approach:
- Press the Add-button inside the Java Libraries section of the Service Group details.
- Select the desired JAR file in the appearing browser window.
Please note: Before being able to use the implementation inside of a Service, the JAR file has to be uploaded to the Service Group.
Please note: For a change of the used Libraries to take effect, the Service Group has to be re-deployed.
If the Service implementation needs access to Shared Libraries, they can be selected inside the section Java Shared Libraries.
You can open Service Groups from nearly wherever they are displayed, e.g. from inside of a Coded Service, out of the Factory Navigation or the Search area of the Xyna Process Modeller. To open and edit a Service Group, double click the item or open the context menu and select Open.
A Service Group can be renamed from inside the Factory Navigation by using the Service Group's context menu and choosing Move/Rename. The following dialog will guide through this process. With this action, all references to the moved object will be adjusted.
Pleae note: The Service Group must not be open while moving/renaming one of its Services.
To remove a Service Group, you have to open its context menu inside of the Factory Navigation or Search area and select Delete from XMOM.
Before deleting an object, its dependencies to other XMOM Objects are checked. For example, if this Service Group containes Coded Services, which are used by a Workflow, a corresponding info is displayed. The deletion can be forced anyway but this will lead to inconsistencies in the remaining XMOM Objects, e.g. the Workflow. Therefore objects with active dependencies should NOT be deleted manually.
Please note: Dependencies are only checked for objects which are deployed. Saved but not deployed XMOM Objects are being disregarded.