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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
