Server Packages

The purpose of the Server Packages is to describe Service Layer components in such detail so that all code files can be generated with complete interfaces. Most of the standard implementation code is also generated, even if the implementation of some methods still have to be programmed by a software developer.

A Server Package typically consist of one or multiple Handlers listing the methods that should be exposed to clients along with one or multiple Documents describing the data structure that the functionality operates. The screen shot below shows an example Server Package consisting of two handlers and the documents used by the handlers.

Figure:  Serverpackage source editor

There are four types of server packages. Activity and Service Packages are used to describe components accessible by clients outside of the application server. There is little technical difference between the two but Activities are supposed to be used by interactive clients whereas Services are used for machine to machine integrations. Utility Packages describe objects that can be used by other packages but aren't directly accessible by clients. Entity Packages are similar to Utility packages but only exist to retain backwards compatibility with IFS Applications 7.5. Entity Packages should be considered as deprecated functionality.

The recommended way of working with Server Packages is to keep things as simple as possible. Try to include all the objects you need in a single Server Package and avoid using Documents from other Server Packages. Start by defining the data structures (Documents) that you want to expose. Then add the Handlers and methods you want to publish in your Activity or Service. These initial steps are best done in the Diagram view but to add more details and to diff models you will want to switch to the Source view.

One of the most frequently asked questions when it comes to Server Package modeling is which type of documents to use. The answer is simple. If you want to access components that you don't know if they will be installed in runtime or not - use LU Wrappers. If you want to publish data from the main database view of a Logical Units - use Entity Documents. If you want to be able to apply Filters, either statically or dynamically, - use Entity Documents. If you want to publish data from database views that aren't the main view - use LU Wrappers. If you want to publish data that isn't accessible using standard selects against a single database view - use Advanced Query Documents since these allow you to specify any SQL statement as the source. If your document doesn't have a direct representation in the database - use Non-Persistent Documents. It's of course important to note that only Entity and LU Wrapper Documents support the standard Save functionality. If you use any other type of Documents persistence has to be coded manually. It's also possible to use Extended Documents. These are Documents that extend a document defined elsewhere and they inherit the attributes published in the original Document along with the functionality supported by that Document (e.g. if the document you Extend is an Entity Document the new Document will also support the Save method.)

This page is generated from IFS Developer Studio at 2021-08-13 08:40.