I’m trying to create a ticketing system on Bonitasoft. A ticket consist of it’s own metadata and it it would be related to a client object(this is not user) and a workspace object. I need some CRUD pages to manage the client and workspace object. What is the best approach to do this. Should I create a diagrams to manage edit and delete both pieces of data or should I put the data in a external database and create some custom api to manage this data?
1 Like
really there’s not enough information to go on.
Personally all my data is external to BDM’s and in database. Others do it the other way round.
Regarless of which you choose there is no reason not to have CRUD mechanisms for any of it. In fact I would encourage it.
There is no need for custom API’s for managing external databases just use what’s already there…it works fine. Connectors are your best friend here…
regards
Seán
Sean,
Thanks for replying I looked at the Procument example and it actually does what I want it to do. But they have a example on how to create a supplier but no example on how to edit a supplier. And having a hard time determining how to implement this. I cant figure out way to pass a the persistence id of a supplier to a process. Should I use the rest api and create a instance of the process and then pass the id to that instance and then redirect to a task?
Joshua Hightower
Ah the perennial question to update or not to update… 
First things first I suppose - I never update. Which is not really true.
Let me explain, and this is why thinking about the persistanceId is not necessary…
In the old days of COBOL we would read a record, update the record and then write it back.
Then the financial crisis came along (actually it wasn’t that but I can’t talk about it otherwise I’d have to…have a guess) and we had to write code that did this:
read a record - save it in temp storage
update the record - save it to temp storage
Start transaction for two phase commit
Write the updated record
Write the temp storage record (before and after images)
End transaction
This allowed the Auditors to manage our work, find fraud etc. and there was a not lot of it. I still work this way - it’s easy for me, and our auditors.
This capability of being able to audit the work, in my mind, should always be practiced.
Therefore when updating a BDO, this is what i would do,
read the Current BDO into a newBDO
display the form using the newBDO
user updates the data
update the newBDO in the Operations tab of the task execution
That’s it, the newBDO becomes the current BDO as soon as the update is complete.
Then you can add to managements delight by giving them an already ready list of changes to the BDO by just listing them out (with obvious details such as date it was changed, by whom was it changed, from which terminal it was changed etc…)
You might think this is a pain, but it is very good practice.
regards
Seán
Sean,
This makes sense. But how would you implement this in Bonitasoft. Right now I’m planning on creating a process in which I pass in a persistenceID as a process variable and basically implement what your recommended. Do you think that is the correct implementation?
I’m travelling for the next few days and will not be able to help much, still don’t see the need of the persistanceId though. I think the process needs to be described more.
regards