From March 15 through March 29, 2014, Dan Short (the CA Gen Product Manager) and I (the CA Gen Product Owner) traveled northern Europe and attended the following user group meetings as well as meeting with various individual customers:
We were well received and there seemed to be a lot of excitement about the amount of focus that CA Gen is receiving from CA management due to the recent organization changes as well as the latest releases and features being added to the product.
One of the most fun things that we did at the meetings was to allow the participants to "vote" on ideas that we taped to the walls of the meeting rooms (see attached pictures). We gave each person five post-it notes and they were allowed to use those notes on one or more of the ideas (or they could use them to create new ideas as well). Although this is definitely not a scientific approach to finding out what you, as the customers, would really like, the exercise did bear some interesting fruit. Out of the 58 ideas that were on the wall, 46 got votes but the following 12 got the most (the total number of votes is the number at the beginning and note that this is across the four user group meetings as well as a couple of customer meetings):
Please respond to this post if you have more pictures, if you attended the meetings and would like to comment on them, or if you have any comments/questions about the top rated (or other) ideas. Note that we did this voting in anticipation of getting the Ideation functionality on the EDGE community site and if/when that functionality is available, all of the ideas that were voted on will be used to initialize that functionality. We will also be using this information to help CA Gen decide what things should be worked on next (from the looks of things, dialog box filters and stored procedures are going to be right up there).
Thanx to everyone who was able to attend and special thanx to all that made this trip possible.
We just posted presentations from the EMEA 2014 User Group meetings under the Documents | Conferences | EMEA | EMEA 2014 folder. Enjoy!
Honestly, while supporting IN and BETWEEN for conditional clauses is useful, I would really kill for supporting a Group View as the source information of data for an IN statement.
There is a significant amount of logic in applications I work on where the number of entries I want to use in a comparison can vary, and having to do different READs depending on numbers is very frustrating.
Are you saying that you would like to have the option of including a view (be it group or entity) as a parameter of the IN clause rather than explicitly entering values? So instead of saying ...IN (3, 6, 9, 12)... you would say ...IN (<entity group="" reference="" view="">, <entity group="" reference="" view="">,...)... ? ________________________________ </entity></entity>
<entity group="" reference="" view=""><entity group="" reference="" view="">
Essentially, yes. I'd like to prepopulate a group view (passed in or constructed), and be able to use that group view as the source of the values for a READ/IF. It's a fairly common pattern in dynamic filtering or duplicate check for pushing into a group view. For example:
SET SUBSCRIPT OF grp TO 1
SET lcl_g type TO 3
SET SUBSCRIPT OF grp TO 2
SET lcl_g type TO 24
SET SUBSCRIPT OF grp TO 3
SET lcl_g type TO 75
+- IF in_request type IS EQUAL TO 4
SET SUBSCRIPT OF grp TO 4
SET lcl_g type TO 36
READ EACH product
WHERE type IN ( grp lcl_g type )
When I first heard about IN being available, I was quite hopeful. But to do this sort of thing as currently implemented would require 4 distinct entity instance views, and I would have to manually fill the unused ones with previously supplied type codes. And that just makes the code messier and less readable. Having a single group view I can populate would make the code more readable, less error prone and easier to debug.
(Edited to provide non-consecutive numbers to better demonstrate the issue)
In your example, it appears that you want to just pass a single instance of a group view to the IN clause whereas I was assuming that all instances of the group view would be passed to the IN clause (i.e. in your example below, the clause "IN (3,4,5)" would be replaced by "IN(grp lcl_g type)". Is that not what you were thinking or are you looking for some way to have it both ways? For instance, an explicitly indexed group view would only pass a single instance whereas an implicitly indexed group view would pass all instance that have data, or something. ________________________________
No, your assumption was correct - I want all instances of the group view to be used. I perhaps wasn't clear enough in my expected requirements.
In essence, what I want is:
If I've got a component that's been called which has a group view with a single workset containing multiple attributes supplied, I want some control over which attribute is used for the IN clause. I don't want to have to alter the component consumer to constrain to a group with with a single workset/entity with a single attribute. I don't want to have to use a local view and do data reshuffling to get what I want. I'd just like to be able to use the group view with a specific attribute as a source of values. How you choose that syntactically would be up to you, obviously.
In essence, the introduction of a useful new ability, without having to (potentially) significantly alter call chains or code flow, just to take advantage of it.
I hope that clarifies my thoughts on the matter for you.
And a couple more pictures John - Dan in the Priory in Belgium, and Michael dealing with the Elephant in the room in Copenhagen!