Server interfaces are defined by the concept of handlers, where each handler contains a set of methods that are callable from clients or other server components, depending on the handler type. Some handler methods are automatically generated from the model, i.e. there is no need to provide any implementation. Other methods, most notably those containing business logic have to be manually implemented. Handlers contain modeled methods, but can also contain manually written implementation methods (which are private to the implementing class). Such methods can only be used within the handler implementation class.
A handler factory class is used to instantiate a handler from the server code, i.e. you always use such a factory to get hold of the handler you want to use, but notice that you can only use handlers in packages to which there is a modeled dependency. Factory classes exists only for entity- and implementation handlers.
Example using an entity handler:
SearchDomainRuntimeHandler handler =
SearchDomainRuntimeHandlerFactory.getHandler();
SearchDomainRuntimeArray searchDomains = (SearchDomainRuntimeArray)handler.query(condition);
There are three types of handlers: Activity handlers, Service handlers and Utility (Implementation) handlers. Whilst Utility handlers are intended to be used internally, Activity and Service handlers offer the public interface of Service Layer within IFS Application.
Technically there is no difference between Activity and Service handlers - both are implemented as Enterprise Java Beans in the Application Server. But the purpose of both types is different. Activity handlers are designed as back-end of the client application and as such typically perform only short actions within a scope of the current user. In opposite, Service handlers are designed to be called from other applications and will complete an entire logical process in a single call. Because of the different purpose of both handler types, there is a different support for code generation as well.
But because there is no difference in the technical implementation, the SOAP Gateway and IFS Connect can access both type of handlers. A handler contains a number of operations (methods). Service layer brings up yet another concept: BizAPI. Simplified we can say a BizAPI is just an alias to an operation (method) in a Service handler. The BizAPI name has to be unique within the entire system. When configuring Integration or sending a request to the SOAP Gateway, you'll typically use a BizAPI name, but it is also possible to use combination of handler and operation names instead. That's why it is possible to use even Activity handler methods in conjunction with SOAP Gateway of IFS Connect configuration. But the behavior can be unexpected, because there is yet another difference between Activity and Service handlers: format of the parameters.
Activity handlers are designed for communication with the client application and send/receive data in binary representation. Service handler on the other hand are designed for usage with external systems and therefore exchange data using XML representation. Because SOAP Gateway and IFS Connect are parts of IFS' integration solution, they too use the XML format for exchanging data. But XML format of IFS record lack the necessary information about attribute state, which explains why, for example, a generated standard save method within an Activity handler will never save any data if called from the SOAP Gateway or IFS Connect.
Access possibilities to activity and service handlers at runtime can be defined in IFS Solution Manager as described in Administrate Security section. Additionally service handlers that define BizAPI's are automatically granted to the the special Foundation User IFSCONNECT, which is necessary for situations where a BizAPI is called through the IFS Connect framework, for example when reading incoming messages without scope of any end user.
Normally a developer doesn't need to think about security when modeling and developing a handler. Note however that security definitions can be applied on handler level only. A handler can contain several methods, so consequently all methods in a specific handler will be granted the same user rights. If it can be necessary to have different security settings for two methods, they have to be placed in different handlers.