How to create idempotent json rpc init scripts?

I would like to import documents during data services initialization. How can I make sure on repeated init execution the documents in dataservices reflect the state that would have been created by running init the first time on a newly created database?

During the course of the project new documents need to be added during init and others need to be changed. This causes a repeated initialization to trigger the update of the data. However for example just using ADD_DOCUMENT would only create additional documents. In case of CMS content for example there will be additional CMS ProjectDM and ContentPageDM documents but the original ones will remain unchanged.

So how can a json rpc operation update an existing document or create a new one if that document is missing?

HI @andreas-fresh-mesa,

DS has option to have JSON-RPC requests using idempotency (Please see our documentation section 5.2 Idempotency). This will allow that every JSON-RCP request is executed just once. Unfortunately, this logic is bound to the HTTP request, which is not available during the server initialization or during Init-App because we use files. DS can introduce a logic to use filenames as request IDs and therefore making sure that each request would be executed only once. For re-importing a file, the database entry could just be deleted. If this is what you need, please create an A12 ticket for it.

DS has no save logic for documents. All our APIs to save documents are split to add and modify for multiple reasons (we have different authorizations for these methods, different logic for Solr and CDD synchronization, Document references need to be created on the client side, …). You could introduce operation SAVE_DOCUMENT but you will be facing the problems mentioned above. DS is generally trying to move in this direction by dropping CDD indexing and Solr we remove synchronization issues, by introduction of UUIDS (as a part of docRef) we dropped a need for DB sequences. The only obstacle that will remain in 2025.06 will be changes in authorization definitions, which we will not do in 2025.06 due to limited capacity.