5.1 The SIS process

The SIS is not planning exactly one process for the transfer direction, but supports a various amount of processes. Each process will thereby be configurated separately as well as implemented and can interact indirectly with the other processes by the data images in order to define a conflict behaviour for instance. Thereby, these processes can separate the data inventory or complement the synchronisation. In case of complementing, two connected records will be synchronised with several processes.

In the setting resources, you normally find a process template for the turnover synchronisation. In most systems, a turnover change is not a change of the master data and does therefore not activate a transfer. In order to offer current turnover figures, this process exclusively transfers the turnover figures for all records and therefore complements the modification synchronisation. As the writing of the turnover figures is a modification in the target system, the process updates the synchronisation information of data images from parallel and complementary processes. This interaction cause that these processes implement a (re)transfer if applicable or no wrong conflict recognition occur.

A separation on several processes is useful in the following situations:

The bidirectional synchronisation is defined asymmetric.

If the panel allocations deviate between the transfer directions, a conflict could lead to inconsistent data.

Conflicts occur from a time simultaneous modification in different systems and often end with the selection of a certain modification and the rejection of the other modification.

For not rejecting only single-sided synchronised panels by a conflict, the transfer of these panels can be outsourced in a further process with an own conflict handling.

You require different filtrations in certain situations.

If you require for instance a synchronisation of the account manager with the representative in Sage 100 / Office Line, but no account generation is requested by the integration, you require a further process which only allocates and transfers this panel for companies with existing current account. A filtration on the available account number can be recommended here.

Sie benötigen in bestimmten Situationen unterschiedliche Parameter.

Each process defines a variety of parameter which can also be data object specific. These parameter cannot be influenced during the synchronisation. If you would like to work with for instance different current account templates, this needs to be implemented by several processes.

Please consider the following when working with several processes:

Even when you are working with several processes, it is recommended to define main processes which display all bidirectional panels and the first generation as well as if applicable implement available adhoc transfer. These processes should also define the conflict handling as these are especially important for bidirectional synchronised panels. For all complemented processes, the conflict solution can be transferred at the main process by the configuration "Write, but leave conflict for other processes". In this case, not all data images will be updated.

You control the highness of the first generation by the compliance regulations. Even when you are not using compliance search, the configuration for "4.3 Behaviour in case of no compliance" will be evaluated for this decision. Here, you need to set "Generate record" so that the process implements a first generation.

A description of the general parameter for processes is following. Plugin specific, additional parameter will be described in the overview of the individual ERP systems.

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	It has nothing to do with if applicable an available mandate number in the ERP system. You find such parameter in connection plugins. These numbers should be assigend continuously if you would like to display several mandates in a target system. This number controls the selection of the numbered SIS panels in the CRM (SIS status, SIS reference, etc.) and therefore which records should be synchronised with which mandates.
1.4 Follow-up process	Besides the interaction of processes by the data images, they can also start parametrised other processes. Thereby, a list of record ID´s will be transferred to the follow-up process which have been processed by the current process. The follow-up process needs to be compatible to the current process uns uses the list as additional source filtration for its own implementation. So for instance all persons of a company can be transferred as soon as the company has been transferred. During the first transfer, such relations should be displayed so that all information are available in the target system.
1.5 AdHoc implementation supported	Such a marked process can be selected if applicable in the source system for the first transfer. You can also use several processes for the first transfer. All marked processes which can record the current record by their processes, will be offered in the CRM.
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 Filtration for source data	This filtration limits globally the data recorded by the process. This filtration is end system specific and needs to be formulated in the correspondent language. Filtrations on CRM data will always be formulated in SQL. Demands to Sage 100 / Office Line use the SData syntax for formulating the filtration.
2.4 Always demand all records from the source	This parameter switches between the modification synchronisation and the complete synchronisation. With activated parameter, always all data will be read and written without conflict verification if changes are existing. This parameter is recommended for a mass update as for instance the turnover transfer.
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.
3.1 Enforce initial synchronisation for the next implementation	This parameter may not be mixed up with 2.4. It does not implement a mass update, but closes the gap by for instance longer inactivity. Furthermore, this parameter will be deactivated again after sucessful implementation. All source data will be loaded and processed according to the filtration setting with this parameter. For each record, a conflict verification will be implemented (difference to 2.4). If the outcome of the verification is that all records are synchronised in relation to the data images, no transfer will take place.
3.2 Behaviour in case of conflicts	The following options are available: Source has priority - The data will be written und all data images will completely or single-sided be updated. Target has priority in the current implementation - The data will not be written and only the own data image will be updated (establish conflict liberty). Skip - The processing of the record will be cancelled without adapting a data image. Write, but leave conflict for other processes - The data will be written and the own data image will be updated, foreign data images will not be updated.
3.3 Behaviour in case of errors	The following options are available: Immediately repeat implementation completely once Immediately repeat implementation differentiated once - only failed records will be repeated Add records for the next planned implementation - processes without time schedule (e. g. pure adhoc processes) implement once a former error repetition. Failed records will be repeated unlimited with the time schedule. Ignore errors Not enqueue implementation again - the process will be stoped permanently until the time-control will be activated again manually
3.4 Varying email address for error notification	Otherwise, the addresses from the server configuration will be used.
3.5 Maximum amount of continuous repetitions	Addresses of companies and contact persons of persons will be synchronised in individual processes. Thereby, for instance persons will be generated not before the superior company already exists. Until then, the contact person needs to be reset. For this purpose, the ID´s of these records will be transferred to the next implementation where then the hierarchy is available. The contact person process cannot determine if the required address will be synchronised at all (e. g. by the the filtration). For not further processing unnecessarily the contact persons, this parameter defines a maximum amount of repetitions. The amount can variously be selected, should however consider the implementation ranges of the individual processes. In case these are deviating, this parameter needs to display the factor. Furthermore, this parameter can be applied in connection with the compliance regulations. For example, the generation highness can thereby be controlled in a several mandate integration.
3.6 No synchronisation information for complementary processes	This parameter will only be considered for new generations. In this case, the synchronisation information will not be written to complementary processes. As soon as a record has been generated, each process generates data images for all involved processes so that these implement a conflict verification and if applicable can determine the synchronity. A conflict verification will not take place without synchronisation information and the record will be transferred. It is appropriate for situations where the target system generates information which should be retransferred to the source system.
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). As soon as a record exists for a data image, this demand is not important anymore. Without data image, a search in the target system will be implemented if applicable and the result will be evaluated with the following regulations. This feature is appropriate for connecting several mandates. Furthermore, this feature can unite for the SIS separated data inventory (e. g. migration).
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. This should be reserved for the main process and not be carried by the complementing processes.
4.3 Behaviour in case of exact compliance	Will be evaluated after made compliance search if the search delivered exactly one result. "Only generate mapping" exclusively generates a data image for the modification synchronisation.
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 process display in the SIS administrator

Besides the configuration of a process, the SIS administrator also offers the opportunity for a direct controlling. For this, you need to click on the desired process in the navigation tree under "Processes" and the process controlling will be displayed in the main area.

It is not important for the controlling which process you are currently observing. As soon as the SIS administrator has been started, all process messages will be recorded and reproached in the particular process displays. The message box has thereby a length limitation of 500 lines so that the resource consumption of the SIS administrator remains controllable. Older messages are available any longer in the area records.

The process display includes the process name and the following buttons at the top:

"Cancel process" breaks the current process implementation. The break can be made with delay if the process is currently in an unbreakable operation.
"Copy window" copys the message text in the clipboard.
"Empty window" deletes the messages in the process display.

The middle area includes the available process messages. Each message will thereby be displayed with its creation date and type.

The bottom area shows a status line with a progress bar and a summary of the current implementation status.

The time-controlling

For an automatic continuous process implementation, a time schedule needs to be defined. You can do this by the menu option "Time-controlling" in the characteristics dialogue of the process.

The time-controlling is separated in two areas: the settings for starting the process and expanded settings for repetition, delay or operation.

The following settings are available:

No time schedule	Deactivates the temporal implementation. This can also be made by the queue without the need of changing this setting.
Once	Unique start of the process to the time provided under start.
Daily	The process will be repeated every x days starting from the beginning time.
Weekly	Start and repetition can thereby be bound on weekdays and weeks.
Monthly	Limitations to certain months and starts dependent on the day of the month or weekday of the month are possible here.

If you are defining a time under "Start", it is the earliest time of the day when the process can start. About this, time windows from 0 a.m. until the determined time can be kept free.

Delay task for maximum

For the case that a process implementation takes longer than the next planned repetition, a direct new implementation can however be planned if the time is within the set time span.

Example: A process with repetition every 10 minutes and a maximum delay of 5 minutes. 15:10 duration 13 minutes → next implementation 15:13 and if applicable 15:20 15:10 duration 16 minutes → next implementation 15:20

Repeat each: ... for the duration of: ...

Starting from the beginning time of the process, a repetition every x minutes/hours/days will be implemented until the duration exceeds.

Expire

Sets a global expire date of the process. No planned implementation will be made after this date.

Examples

A daily implementation every 10 minutes from 8 a. m. until 6 p. m. starting from 06.05.2015

Start: 06.05.2015 08:00:00

Setting: Daily with every day repetition

Expanded setting: Repetition every 10 minutes for the duration of 10 hours

A daily implementation every 10 minutes from 0:00 a. m. until 11:59 p.m. starting from 06.05.2015

Start: 06.05.2015 00:00:00

Setting: Daily with every day repetition

Expanded setting: Repetition every 10 minutes for the duration of one day

Strategic time planning

The following facts need to be considered for the time planning of your synchronisation processes.

A 24/7 synchronisation with the CRM concluds that the CRM application cannot be closed anymore due to inactivity. This can perhaps negatively influence on the resources usage and therefore on the CRM. The standard idle time of the webserver is 20 minutes and can be configurated in the IIS administration at the application pool. Plan the daily start time of your processes so that the CRM application can reach this idle time from 0 a. m. and can therefore be closed.

The meta data processes of the SIS transfer for instance selection groups to the translations of the CRM. These processes cannot provoke a meta data update in the CRM. This concluds that new or modified meta data are not available anymore in the CRM, although they have been saved in the translations. Hereby, the planned closing of the CRM application also helps. As soon as the CRM has been restarted, the modified meta data will be loaded and are available. Plan the meta data processes for instance at the end of a day before the inactivity phase begins.