I'm new to the IBM Rule Designer (8.8.1) and my team has inherited a project that contains numerous rule flows, subflows, rule/action tasks, etc. I'm attempting to document at the task (ie. rule flow node) level, but there are instances where 100+ rules are included in a rule task. Is there a way to query a rule task to quickly find the number of rules that are associated with a specific rule task? I couldn't find any query condition phrases or objects that appeared to say something like Find all business rules such that each business rule [is contained within <a rule task>].
Any ideas on how to accomplish that? Is there a way to turn the results from a list of rules into an integer count of rules?
Thanks for your help; please let me know if clarification is needed.
Short Answer: I don't think there is an easy way, but there is a way.
Using queries, I think the closest you can come is to find all rules in a rule package. It is common (and good) practice for the rule tasks to line up with rule packages, so that is often useful or good enough. If the rule selection specifies individual rules, queries probably won't help.
It is easy to go the other way -- to find which rule task(s) a rule appears in. Just right-click on a rule, either in the Rule Explorer view or the Rule Editor view, select 'Find Rule Dependencies' then select 'Ruleflows which may select this rule'. Not what you asked for, but often helpful.
Note: When you run a query or do any other search, the results appear in the Search view and the number of matches is included at the top. Be aware that this count may include the same rule more than once if it appears in multiple rule tasks.
What I would do to count the rules of a rule task that are specified individually is look at the source code for the rule flow. Open the ruleflow in the Ruleflow Editor and select the *.rfl tab. Scroll down or search to find the tag that you are interested in. You can turn on line numbering (right-click, Preferences, Show line numbers) and do the math yourself. Or you can select the tags from the , copy it to the clipboard, and paste it into another program that counts lines. You could use Excel, which automatically counts the number of items selected, or another editor, or even create empty file in Eclipse with line numbering on.
Related
We have agile / devops culture -based teams who have a need to track work that has been planned and prioritized at an expected pace, vs work that came in for immediate handling. Some are bugs, some are tasks, some stories, etc.
We're thinking that adding a custom field is the way to go, with potential values of Maintenance and Enhancement. And of course, the hardest part: What would the field name be?
Is there a better approach? We don't think that a new work item is really it, but we could be convinced otherwise.
Additionally, we've looked at all of the canned fields and don't see an obvious field that fits, but we would prefer to use the built-in fields where it makes sense.
What, if any, is the recommended approach? I'd be very surprised if we're the first with this need.
A custom field doesn't have big difference from predefined field, so you can feel free to create one when no existing predefined fields can meet your needs.
I agree with your thought of adding a custom field. As for the field name, we can simply name it PlanStatus,PlannedOrNot or whatever you like...
You only need:
1.One inherited process based on Agile process template.
2.Edit Bug type and create the field.
Then edit other workItem types who also need this field. (Edit=>Add an existing field=>PlanStatus)
3.Then you can create a bug/epic with PlanStatus field and you can use the newly created field in Query. Besides, you can add a widget in Project OverView=>Dashboard to track the planned/unplanned workitems. (Chart for WorkItems widget or Query Results widget or what...)
I was looking on VSTS, but I didn't found how to estimate our Tasks/users story in hours instead of Story point.
Is this possible?
I know the pro(and cons) of story points, buf for now our team want to move progressively with agile, and we don't want to start to estimate in story points.
Thank you!
Edit as requested, I currently use the agile template(but open to change)
Declare "One story point is equal to one hour" and use the existing field as-is.
TL;DR
Use the built-in scrum template
If you use the built-in Scrum template Tasks have Remaining Work and PBI's have Effort. Nothing says Remaing Work = hours or Effort = story points.
If you want to estimate your tasks in number of 4 hour work blocks it will take to complete you can do that, if you want to do it in hours you can do that. Same goes for effort you can put any number in there you want as long as you make sure everyone in your team understands what 1 or 5 or 10 means.
So if possible switch to the scrum template, your question is exactly the reason why these fields have a more generic name than Story Points or Remaining Hours in the scrum template. Added bonus is that your team can switch definition if they feel like some other number or unit suits your estimation process better.
This blog post makes a good comparison between the built-in different templates:
https://nkdagility.com/choosing-a-process-template-for-your-team-project/
If you are an administrator in VSTS select the VSTS button at the top left of the screen. Then select then select the cog.
This will take you to a page where you can edit a number of settings. Select Process.
In the process window choose the process your project uses. You can see which one your project is using by the numbers on the right hand side of the process. Once you’ve found your process select it by clicking.
Then choose the work item type you wish to change. So in this instance user story.
Once in the task you want to change select add group and name the group want to add and select it's placement on the card.
When the group has been added select it and choose the ellipses (...). Then select Add Field. Customise the field to be either a new one of your choosing or choose a predefined one.
Once you have added this step repeat the process on this page to customise and style the task how you like. Once done navigate back to your project in VSTS and the changes will be applied
What is the best way to allow backend users to edit variables?
For example, I have a TYPO3 that sends out various e-Mail notifications and I want the backend users to be able to globally change the recipients. I started with template constants, until I found out, that backend users cannot edit the "template" module.
So what would be the best way to achieve this? I'm using Typo3 8.7.7
I would create a configuration record which can be edited by the backend users.
one way would be to include one file from fileadmin/ into the constants definition of typoscript. This file editors could change. But that could be a security risk, as the editors could define any constants.
the next option would be to define additional fields to the pages record, where these values could be set by any editor. In typoscript you access the field (maybe with slide = -1, so the value needs to be set just once)
another option: add these fields to a (special?) CE (ContentElement).
last option: use std CEs (e.g.HTML-content) at special pages or columns and use the content field (bodytext). (HTML-content has the advantage that the bodytext field is stored unmodified.)
Cleanest and leanest option would be option two (additional fields to table 'pages'). Option three and four are possible with pure typoscript, but you need to use CONTENT or RECORD object. If you use fix uids: remember that your editors might delete the CE and add a new CE with the same content (but another uid)
Addition:
As #Thomas-Löffler in his answer said:
you also can add a new kind of record/table, where an editor can insert or change the global values. Handling is like pages or tt_content. you can differ if your records are global (pid = 0, or special storage page) or dependent on page tree (rootpath), so you can have differnt values for different page subtrees.
I like Thomas‘ answer for providing a dedicated place to store the configuration option instead of putting it e.g. to pages because your configuration option is not bound to a page context.
Nonetheless for me personally it feels a bit odd to create a dedicated table for it. A table that would never hold more than one record.
That leads me to the conclusion that a key-value storage would be the right thing to use. Fortunately, TYPO3 ships System Registry. The only downside is that there‘s no interface for it so you‘d have to come up with your own forms to fill it. That‘s much easier if you go with Thomas‘ solution…
A clean and easy way is setting up a backend module with a form to set the email addresses.
Then you can grant the access right to a specific group or user and they are ready to go.
I have a set of rules for each of my user. Right now, these rules are setup in a file. But I want to allow my users to modify / add rules. The rules aren't that complicated. For instance, below are a couple of rules:
rule "Rule 1"
when
$order : OrderInfo(getOrderDate() < new Date(...)
then
$order.setReturnEligibility(false);
end
rule "Rule 2"
when
$item : ItemInfo( nonReturnableCategory.contains(getItemCategory().toLowerCase()) )
then
$item.setReturnEligibility(false);
end
rule "Rule 3"
when
$item : ItemInfo( isFinalSale())
then
$item.setReturnMethod(...);
end
I want to build a UI similar to Drools workbench. But this is for the end customer, so I want it to be a very simple, user-friendly UI. And I was planning to store the rules in a database.
I want to allow the users to add new rules and modify existing ones. For instance, if Rule 3 above was not available, the user will have a dropdown in the UI, where they can select the item categories which are not returnable. Or they can enable or disable any of the rules etc.
What I wanted to know is, what is the best way to maintain the rules? Should I just have the entire rules file as a string in DB with some sort of place holders, and modify the string as and when the user adds / updates the rules? I'm using Drools 6.2. I know the question is kind of vague, but I have no idea how / where to begin, so any suggestion is appreciated.
Thanks.
If modifying an existing rule means that only the constraint changes the "text with place holder" might be a good idea.
However, I would not store the entire DRL file as a DB entry. Probably a system where individual rules are stored as entities would work best. Attributes would be a name, the text, an "is selected" attribute etc.
I'm looking for a way how to split job execution in talend studio according to actual file row - I'd like to process file rows starting with "DEBUG" in one job branch and another rows in another job branch. It that possible?
To do this, use a tMap component. Your job will look like this
t*Input--row-->tMap--out1--->tFileOutput*
--out2--->tFileOutput*
In the tMap component, you have input on the left and output on the right. In your output table, select "Activate expression filter" and use the text box to define your filter-- only rows that match that filter will be ouput from that connection. You can have as many output tables and filters as you need.
Using tMap is cool, but if number of output stream is not defined and fixed, tMap is not a good choice.
In this case using iterate link or tjavaflex can help you:
Have a look at this tutorial on "how to split a file into many files regarding a key on each record" which explains how to solve this kind of task. It is actually only available in french. The tutorial shows 3 different technics to achieve this task.
Finally I used tExctractRegeFields component - simply defined regex for matching lines. The most important (and I didn't know before) is that you can connect components with different types of connections. I did right click on used component a chose Row > Reject for new branch in job as described in question.
We can do it by using tfileoutputdelimited and tfileinputdelimited.
We have one option in tfileoutputdelimited in advanced settings and check option split out files in several files.