5.7 The demanding plugin

The demanding plugin is a generic process plugin in order to transfer a desired data demand in an available data object. Thereby, an update behaviour can be reached by compliance regulations. Furthermore, the implementation is possible in the context of another process. It is also possible to formulate a mutation related demand with the demanding placeholders "LastVersion" and "LastDatetime".

In the SIS, these plugins will for instance be used for the transfer of meta data respectively selection lists and require an extended license for the implementation.

1.1 Displayed name	will be used in the SIS administrator and in the CRM as designation for this process.
1.2 Description	can include administrative hints which are only visible in the SIS administrator.
1.3 Serial number of the mandate	This parameter has no significance for demanding plugins.
1.6 SIS server limitation	For an horizontal scaling, it can either be worked with a load related separation on individual SIS server or you can allocate targeted, fixed, individual processes to a certain server. In this case, the implementation is exclusively possible by this server.
2.1 Source connection	Selects the source connection.
2.2 Target connection	Selects the target connection.
2.3 Process	So you determine a process context if applicable. If this panel remains empty, the defined demand will be implemented once and the results will be processed. In case, you are selecting a process here, the demand for each data image of the process will be implemented and processed. In this case, the demanding placeholders "TargetId" and "SourceId" are available, which will be filled by the data image.
2.5 Second filtration for demanded and transformed data	In certain situations, limitations cannot be realised exclusively by the global filtration (e. g. current account limitation for address synchronisation). This filtration will be implemented after the demand of the source data and the followed transformation if applicable. It will always be formulated in SQL and can access on columns in the hierarchy by the same point notation how the transformation will be used.
2.6 Column name for LastDatetime	This parameter is available for source systems with data related mutation recognition. Please provide here the column name of your data scheme which includes the concerned date. This value can be used for a continuous implementation as placeholder in the demand.
3.1 Allow asynchronic processes	This parameter can be used for a vertical scaling of the process. Dependent on the end system, this can lead to a higher load and therefore performance losses in the end system.
3.2 Behaviour in case of errors	The following options can be selected: Immediately repeat implementation completely once Ignore errors Not enqueue implementation again - the process will be stoped permanently until the time-control will be activated again manually
3.3 Varying email address for error notification	Otherwise, the addresses from the server configuration will be used.
4.1 Demand for determining compliances in the target system	This demand needs to be formulated in the syntax of the target system and can work with placeholders (double hashtag or point notation). You can set up an update behaviour with this parameter. Define a demand with clear data from your source which are available in the target. In case, this demand will find demanding records, the following parameter control the update.
4.2 Behaviour in case of no compliance	This parameter will not only be used in relation with a compliance search. It also serves as global decision if this process should generate new records.
4.3 Behaviour in case of exact compliance	Will be evaluated after made compliance search if the search delivered exactly one result.
4.4 Behaviour in case of ambiguous compliance	Will be evaluated after made compliance search if the search delivered more than one result.
5.1 Use data base connections for writing actions	This parameter is available at processes which have a CRM as target connection. With activated parameter, writing actions will be implemented by data base and not by webservice. This is not recommendable for a modification synchronisation as no business logic will be applied and the mutation recognition is neither possible. This parameter is appropriate for mass updates.
Adapter name	Provides the name of the used plugin.

The time-controlling in this plugin does not differentiate from the time-controlling of a synchronisation process.

In the menu option "Demand", you define your data source. Provide a desired SQL demand and determine the data scheme. In the bottom list, the scheme will be provided. Now, you still need to determine the target of the transfer. Under "Target-Object", all object types can be selected which are defined as writable by the underlying connection plugin. After selecting the target, you can continue with transformation and allocation like in any other process.

The following placerholders are available for the demand:

Mandate	Mandate information which will be delivered by the connection plugin.
SourceId	Source information of the data image from the selected process (2.3). Please consider the writing style of data sources with several primary keys.
TargetId	Target information of the data image from the selected process (2.3). Please consider the writing style of data sources with several primary keys.
LastVersion	Will be replaced by the version number of the last implementation. The version number will be provided by the connection plugin.
LastDatetime	Will be replaced by the date of the last implementation. It is not identical to the implementation time, but is directly based on the data. Please provide therefore the column name under 2.6. The maximum of the processed data will be reproached for the next implementation.

A CRM connection returns all for the usage in the webservice released tables and can also write these.