Rick, I wasn't discussing things that 9.x is doing...i was expounding on an idea that Thad was discussing regarding synchronizing data....just a thought...not something they are currently doing, or to the best of my knowledge, something they plan on doing :)
On Fri, May 15, 2015 at 10:23 AM, Rick Cook <[email protected]> wrote: > ** > > So, it's changing the degree of normalization of the data model. That > doesn't sound quite like what Remedy is doing in v9, but it seems to be > moving in that direction. For better or worse, that structure has defined > Remedy from its competitors through the years. > > Rick > On May 15, 2015 9:17 AM, "LJ LongWing" <[email protected]> wrote: > >> ** >> It's been a few years since I took the Force.com training....but I seem >> to remember that you could say something similar to 'I want this field on >> this form to be the value on that form (here is the definition of how to >> get the other value 'association')....and then from that point forward, the >> two values were the same...not to say that it stored it in two places and >> synchronized it...it stored it in one place, and made the other place a >> reference to the first place. >> >> This would essentially be a new 'type' of field, a reference field, that >> would never contain its own data, but instead, be a reference to the other >> data....kinda like a symbolic link works with file systems....that would be >> kinda cool. >> >> On Fri, May 15, 2015 at 10:11 AM, Thad Esser <[email protected]> >> wrote: >> >>> ** >>> Doug, >>> >>> From what I'm understanding, this feature is currently geared toward >>> whether or not the associated records exist. Any chance it could develop >>> into also being data-focused? For example, let's say you have a People >>> form and someone's Full Name changes. You could then define associations >>> to other forms in such a way, that the Full Name field on the associated >>> forms updates automatically. Sure, this is done with filters now, but you >>> have to keep track of everywhere the data needs to flow. I suppose >>> associations doesn't change that, but then it would be part of the data >>> model at least. >>> >>> Or stepping back a level - maybe not just data-focused, but associating >>> fields into a group on a given record. For example, let's say you have a >>> Service Request form, with a group of fields that represent the "Requested >>> For" person.. First Name, Middle Initial, Last Name, Login ID, Person ID, >>> etc. Changing the Login ID or Person ID, would then change all the >>> others. Middle Initial seems to be a favorite of BMC's to forget. Having >>> an association defined with automatic updates might help. It has gotten >>> more consistent with 8.1 and the service calls, so maybe I'm carrying some >>> baggage on this one. :-) >>> >>> Anyway, looking forward to the future, >>> Thad >>> >>> On Thu, May 14, 2015 at 11:57 AM, Mueller, Doug <[email protected]> >>> wrote: >>> >>>> ** >>>> >>>> Thad, >>>> >>>> >>>> >>>> Yes, the Association feature is a major new feature. And, the 9.0 >>>> release has introduced the basics and the possibilities and leverage of the >>>> feature are just getting started. >>>> >>>> >>>> >>>> The 9.0 release uses the Association feature in two major ways: >>>> >>>> >>>> >>>> 1) To delete child records when the required parent record is >>>> deleted. So, if you have a master record and then have other forms with >>>> additional details, the association will automatically delete the children >>>> when the parent is deleted. Associations have a configuration for whether >>>> they enforce this flow or not. >>>> >>>> 2) For archiving. So, archiving the parent, takes all the >>>> children with it automatically. >>>> >>>> >>>> >>>> Now, the base feature is about defining the relationships and >>>> interconnections of forms – directly and through association tables. You >>>> can follow the associations for any number of reasons. >>>> >>>> >>>> >>>> Think about some other things: >>>> >>>> >>>> >>>> Producing an diagram of the relationship of forms to form an >>>> application is now a simple matter of following relationships AND you know >>>> whether the association is a dependent relationship or not. >>>> >>>> >>>> >>>> What if DSO could be configured to “follow associations” so that >>>> transferring the parent record would transfer all children records too? >>>> >>>> >>>> >>>> What if we could configure the system to have row level security flow >>>> to children from the parent so any change to a row level security field on >>>> the parent flows that change to all children records as well? >>>> >>>> >>>> >>>> What if you could define table fields to just “follow the association” >>>> rather than having to define the target form and qualifications on it? >>>> >>>> >>>> >>>> What if you could export data by just specifying the parent record and >>>> all children record are exported along with it (or imported..). >>>> >>>> >>>> >>>> What if… >>>> >>>> >>>> >>>> There is a lot more that this feature can do and will allow. >>>> >>>> Working with applications that involve collections of forms with >>>> inter-dependent or just inter-related data will be much easier and will be >>>> able to be done in a more global, consistent, and systematic way rather >>>> than custom logic for each set of interaction. >>>> >>>> >>>> >>>> >>>> As an aside, there is also much more that is possible with archiving >>>> now that this is in place and you should see some very cool new features >>>> related to archive still to come in releases post 9.0. >>>> >>>> >>>> >>>> >>>> >>>> I am glad that you are seeing some of the possibilities that this >>>> feature opens up within the system – some available already (archiving and >>>> delete) and others to come. There are additional features – both with 9.0 >>>> and some coming beyond that will also provide basic capability that can >>>> then be leveraged in many different ways. (One of my favorites by the way >>>> is the dev-to-production or packaging or deployment manager – whatever name >>>> they settled on – feature. It has a lot of value in 9.0 and there is much >>>> more coming that will help transform how promotion of change is done within >>>> the environment.) >>>> >>>> >>>> >>>> As always, we would love to hear what you are doing with the features, >>>> how you are leveraging them beyond the defined uses. And, what is missing >>>> from them that would make the functionality even more powerful. >>>> >>>> >>>> >>>> Doug Mueller >>>> >>>> >>>> >>>> *From:* Action Request System discussion list(ARSList) [mailto: >>>> [email protected]] *On Behalf Of *Thad Esser >>>> *Sent:* Thursday, May 14, 2015 9:38 AM >>>> *To:* [email protected] >>>> *Subject:* ARS v9.0 - New Server Object - Associations >>>> >>>> >>>> >>>> ** >>>> >>>> Has anyone else taken a look at the new "Association" server object for >>>> version 9.0? I've only read the docs (haven't played with it yet), but >>>> this seem like a huge new feature, with possibilities way beyond just >>>> archiving (which is what the docs say its being used for). >>>> >>>> >>>> https://docs.bmc.com/docs/display/public/ars9000/Associations+overview >>>> https://www.youtube.com/watch?v=E4v0X2SimKY >>>> >>>> >>>> >>>> Just curious what others thought, or if I'm nerd-ing out too much. >>>> >>>> >>>> >>>> Thad >>>> >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>> >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
