It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×10,826
×1,198

question asked: Jun 08 '15, 10:09 a.m.
question was seen: 2,934 times
last updated: Jun 09 '15, 1:46 a.m.

Related questions

FAQ - How this Forum works

client side vs server side deliver pre-condition advice

0
Nicolas Dangeville (316●3●24●25) | asked Jun 08 '15, 10:09 a.m.
JAZZ DEVELOPER
I have a question about client side vs server side deliver pre-condition, that a customer asked and I want to confirm that my understanding is correct.

My customer wants to implement a control on new files being created. The work occurs in the RTC client.
1/ Is there a way now to trigger processing at check-in ? That would be the best place to do it, so that the control would be performed as early as possible.
2/ the control that the customer wants to do might be expensive in some cases. I understand that precondition running on the server side run in the context of a transaction. Delaying the commit of the transaction is not good for other transactions. In this case, is it safer to run this control as a client-side deliver pre-condition (if check-in is not available) ?

Thanks,

Nicolas

One answer

Most liked answers ↓|Newest answers|Oldest answers

0
permanent link
Ralph Schoon (63.1k●3●36●46) | answered Jun 08 '15, 11:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Nicolas,

as far as I know there is no extension point for check in. I have no solution to that. You would maybe want to make sure that not more than on file goes into a change set and I think you can't. All you could do is check that at deliver.

In general you want to have server based operational behavior, rather than client side, because it is much easier to deploy and maintain (only on the server).

Client side behavior is only needed if the information it acts on is only available on the client. E.g. a syntax checking program or something like that.

I don't think you gain anything in the transaction department, since the transaction spans the client as well as the server.
Comments
Ralph Schoon commented Jun 08 '15, 11:11 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Custom client side operational behavior only works in the Eclipse based clients. We don't have a way to extend the other clients. So you would have to make sure it is installed everywhere and fails if not.

Nicolas Dangeville commented Jun 08 '15, 3:22 p.m.
JAZZ DEVELOPER

Thanks Ralph for the answers.

In this case this is for the Eclipse client only so that would work. And yes I was planning to make it fail if not installed.
The transaction piece is the one that I care about here. I thought that the service call was done after the client pre-condition would run, and therefore a client pre-condition would not be part of the transaction that is driven by the service call and would not block it. But maybe I'm wrong ?

Ralph Schoon commented Jun 09 '15, 1:46 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The whole point of a pre condition/advisor is to be able to prevent the transaction from finishing. I don't know all the glory details, but if the advisor fails, the transaction is not performed. Again, a pre-condition is to control behavior and not to change the data of the item.

A follow up action can issue a second save after the transaction finished and is allowed to modify the item this way.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.