• Can CXInsight handle this kind of information?

• How does CXInsight handle these break downs?

• Can China continue working and will the data be synchronized when the connection is active again?

• If I integrate a very large zip file onto the CXInsight client in China from the server in Europe, what happens if the internet connection drops for 15 min?

• Do I get a warning message on the clients screen?

• Will the integrate function be automatically restarted?

• Is there any chance that elements of the zip file will be lost?

• Can CXInsight damage our information, generate wrong information, loose information, etc.....?

CXInsight can certainly facilitate this, because it is completely independent from any kind of other system. For example in CXInsight every customer can be defined as a project or with even higher granularity, every single order can become a project.  The user can define within the project template a standard directory structure, with maps for i.e. customer specifications, quotations, purchase orders, delivery notes, invoices, etc. Every time the user generates such a new project, automatically a new standard folder structure will be generated with a choice of project templates of course.
 
One of our manufacturing plants is located in China and is internet connected to the mother company with a lot of breakdowns of the line connection.

The following steps execute as a single transaction (so if any part fails both client node and project node are restored to the previous state).
 
1.    The synchronization prolog synchronizes the client node and project nodes workspace copies. In your example assuming there are no other files, then this step does nothing.
2.    The integrated operation executes on the project node, changing the project node copy of the workspace.
3.    The synchronization epilog synchronizes the client node and project nodes workspace copies. In your example this transfers the changed TGZ file to the client workspace copy.

For most operations CXInsight does not require a connection to the server and allows the maximum "offline" support possible, so for example tasks can be added to a project in an offline state.
 
Assume a very large zip file is integrated on a CXInsight client in China from the server in Europe?

The following steps execute as a single transaction (so if any part fails both client node and project node are restored to the previous state).
 
1.    The synchronization prolog synchronizes the client node and project nodes workspace copies. In your example assuming there are no other files then this step does nothing.
2.    The integrated operation executes on the project node, changing the project node workspace copy.
3.    The synchronization epilog synchronizes the client node and project nodes workspace copies. In your example this transfers the changed TGZ file to the client workspace copy.

Yes.  Usually "transaction aborted due to a dropped connection".

No.  This will depend on the design goal that all updates should be clear, atomic and confirmed.  In essence, a user is free to work within his workspace even when the connection is down. Operations that require an interaction with the project by definition require a connection to the project node.  CXInsight's workflow design is intended to minimize the amount of work a user must do with the project node.

No!
 
We entrust valuable, important information to CXInsight.

CXInsight holds all file data as regular files on the file system of the the host operating system, so important files held within CXInsight are as secure as the file system / hardware implementation allows. Obviously a regular backup strategy is essential to enable recovery from hardware failure. The CXInsight server double checks each file as it is recorded to ensure the recorded data matches what has been entered.
 
CXInsight's distributed architecture provides extra resilience as work in progress is duplicated on the user's workspace. This has two benefits.
1.    In the event of a system failure at the server, following recovery from server side backup's interim changes from the distributed clients will automatically be applied.
2.    In the event of a system failure the client's workspace can be recovered from the server side copy.
 
In practice this means that in most cases even interim changes that occurred since the latest backup can be recovered which obviously gives an even greater degree of resilience when compared to data held outside CXInsight (or even in many other data management systems). If the user checkpoints their workspaces then this robustness further extends to secure client changes that have not been checked-in yet!

In a worst case scenario of catastrophic software failure, the file based design of the CXInsight repository means that all recorded data is still recoverable.