“Generic” updates using Mass Data Run structure
INTRODUCTION
Hello there!
In this document I’ll try to explain a way to create mass updates taking advantage of the MDR structure. Only one “reusable” MDR is needed. I created this approach because:
- At a certain point, you always have to update a lot of things that you can’t do using the available tools.
- Workflows cannot be scheduled to run every day, every week etc.
- I don’t want to create one MDR for any operation I want to perform.
- All the logic is in the code, so you can do a lot of things.
My intension here is not explain how to create a MDR. There are many posts and documents explaining it. I’m focused in a different way of using it.
This “trick” helped me many times to update values and perform complex tasks in C4C and, eventually, no deploy is needed.
I’m still learning C4C development and I’m sorry if I wrote something wrong and for my english grammar mistakes. I hope you like it and, if necessary, please leave a post to correct me.
CREATING THE MDR
- Create a BO named GenericMDR.bo.
- Create the elements Type and Operation.
- Both elements should be codelists.
- Type represents any entity you want (ex.: TICKET, ACCOUNT, OPPORTUNITY etc).
- Operation represents any operation you want to be applyed over the entities (UPDATE_ALL, UPDATE_TICKETS_BASED_ON_CUSTOM_LOGIC etc).
businessobject GenericMDR{
[Label(“Type”)]
element Type: GenericMDRTypeCode;
[Label(“Operation”)]
element Operation: GenericMDROperationCode;
action Execute;
}
- Create an action named Execute.
- In Execute action, add code for each combination of Type x Operation.
…
switch (this.Type)
{
case “TICKET”
{
switch (this.Operation)
{
case “UPDATE_ALL”
{
/* Add code to update all tickets, for example. */
}
case “UPDATE_TICKETS_BASED_ON_CUSTOM_LOGIC”
{
/* Add code to update tickets based on any logic, for example; */
}
…
default { }
}
}
case “ACCOUNT”
{
switch (this.Operation)
{
case “UPDATE_ALL”
{
/* Add code to update all accounts, for example. */
}
case “CLEAN_ANY_FIELD”
{
/* Add code to clean some specific field, for example. */
}
…
default { }
}
}
case “BOMB”
{
switch (this.Operation)
{
case “ACTIVATE”
{
/* Add code to update any object or perform any task. It can be edited directly in PRD using correction for emergencial updates (Be careful, with great power comes great responsibilities. Test a lot before running in production =P ) */
}
default { }
}
}
…
default { }
}
- In GenericMDR.bo, create a query named QueryByTypeAndOperation for the MDR (Type and operation must be used as selection parameters and result).
- Create the MDR for GenericMDR.bo.
- Create the MDR screens.
- Add values to GenericMDR.bo with the combinations you want, using webservices, fileinput or any other method you prefer. For example:
| NodeID | Type | Operation |
|---|---|---|
| 1 | TICKET | UPDATE_ALL |
| 2 | TICKET | UPDATE_TICKETS_BASED_ON_CUSTOM_LOGIC |
| 3 | ACCOUNT | CLEAN_ANY_FIELD |
| 4 | BOMB | ACTIVATE |
- Add permission to access the MDR workcenter.
- Access the MDR workcenter and create one instance for any combination of Type x Operation.
- Schedule all the instances. For example:
- TICKET with UPDATE_ALL will run every day at 3 am.
- ACCOUNT with CLEAN_ANY_FIELD will run every mouth.
- BOMB with ACTIVATE will run immediately.
Best regards,
Alexandre Kaminagakura \o/
Hi Alexandre.
This is a creative way to use MDRs - I like it.
I actually used a similar approach to perform data structure change-related updates to various business objects, however your way is more universal and thus versatile.
The only drawback I experienced is that that you have to create the bo instances initially.
Hi Ludger.
You're right, create BO instances is a drawback but, unfortunately, we can't avoid it. But anyway, usually I create it using webservices call by SOAPUI. It's no big deal..hehe
Thanks for you comment =)
Regards.
Hello Alexandre,
Even as I found your way very creative 😎 I hope the number of entities which are handeld in the custom logic is not too big. Because you have lost all advantages of the "Mass Data" Run. 🙁
Bye,
Horst
Hello Horst,
For sure, big entities may have performance problems and this approach just takes advantage of the MDR structure to help in specific situations. But as you write the code, you can filter your queries based on flags, dates, id intervals etc. When I first used this approach, I used the current date as filter and every day I scheduled a clean operation on a particular object. It took days to complete but I wasn't worried about it. At least, no manual interaction was needed.
Well, it's just an idea that saves me eventually..hehe
I changed the title, it was a little bit confusing.
Thanks for the comment.
Best regards,
Alexandre.
Yes, I agree with Horst, one loses the advantage of "Mass Data".
However this application of MDRs fills a gap one otherwise does not have in the ByDesign/C4C Platform:
Thus, what Alexandre indeed does here (and I already said I used MDRs in similar ways) is to remove the "Mass Data" part of MDRs and do single scheduled action calls.
So as long as there are no programmable scheduled single action calls, (re)using MDRs this way is the only method I know to achieve this.
This is still not an ideal replacement for the requirement stated above since one has to create at least one object instance somehow.
If it would be possible to define "call this library action once a day at 2am" that would be my preferred solution but alas this is not supported so using MDRs this way is the suitable replacement.
Best regards,
Ludger