I used a lot of Plug-in code to implement business logic in CRM but now I've came up with this feature called Custom Workflow Activity.
now i wonder When to use these custom workflows over Plug-ins ?
Code Activities are custom steps which can be inserted into one or many different workflows. Kind of "plugins" but used to be inserted in workflows.
Workflows give you more feedback because they are represented visually in CRM, so non technical people can see the status of a workflow, and the steps which were executed since the start. Workflows are also executed in the Asynchronous service so they run asynchronously, plugins run synchronously, inside the application pool.
So workflows are also better for long running processes.
With that being said, plugins are still helpful when:
You need to have an immediate response, because they are triggered and executed inside CRM's application pool and,
You need to run anything inside the transaction, so they can abort it by raising an exception.
Example: you have an integration with a 3rd party service, where a record can't be created in CRM unless something is validated on the other side. Another example is concurrency: the auto-number plugin is a plugin because it needs to lock the database in the transaction, otherwise multiple concurrent threads could create duplicate IDs.
So, the answer, like always is: It depends. :)
I went deep into the subject myself and found interesting things i want to share,
So here is the complete list of compare :
Plug-in's only fire on data change like updating or creating records but custom workflows take part inside a process ( workflow, dialog, ... )
As a result , workflows not only can be triggered on data change, but on demand at anytime at any point inside their process. As you might have already understood, It is the real flexibility needed for implementing complicated business logic.
Plug-ins won't accept arguments or passed-data,
But custom workflows make it possible by using InArgument properties like below :
[Input("Case")] //label of the field shown in workflow
[ReferenceTarget("incident")] //if using EntityReference, must point the type
public InArgument<EntityReference> yourArg { get; set; } //almost every data type is supported
Workflows can be simply used and manipulated by business users.
Custom Workflows are absolutely reusable. with one register you have a piece of business logic that can be used in several situations.
in some cases you might even happen to write a code which can be used upon many different entities.
So far you know that custom workflow is more reliable than plug-in , but the point that makes a plugin's take over custom workflow is when you are validating data changes and eventually need to revert those changes . of course this is possible in Custom Workflows but it's much more easier to add a plugin than workflow.
and bare in mind that plugins run faster! (as i tested it myself)
However profiling workflows in CRM is still bugged out !
Many of the developers or MS CRM beginners get confused in some scenarios whether to go with Workflows or to go with Plugins, as both can be used and has ability to perform specific task at server side.
Plugins and workflows have some significant differences like limitations in event messages, Triggering points.
You can refer the below link for complete understanding of differences-
https://mscrm16tech.com/.../workflows-vs-plugins-in-ms-crm/
Related
I am doing data analysis on GitHub projects and I want to filter projects having continuous integration (on GitHub).
There are two types of checks and statuses on GitHub: Checks and Statuses! Projects can use GitHub Apps to run checks or mark their commits with external services (CI or other) [source]. My question here is: does having GitHub Checks (or statuses) results available for a project mean that the project is using CI for sure? If not what other factors should be presented to say a project is having continuous integration?
Possibly. But you can't be sure. It means that some check runs and some status is updated. But without looking at the automation, there is no way to conclude that Continuous integration takes place.
Maybe it checks whether the contributor has signed a contribution agreement.
Maybe it checks for the presence of a Issue id or an attachment.
Maybe it updated some external system (like Service Now) so the issue can be tracked there as well...
Checks and statuses are used in many different ways.
And Continuous Integration looks different for different technologies. Some languages need to be compiled, others won't need that. They'd hopefully have some kind of tests to validate nothing broke during integration, but there is no surefire way to know as it may simply be running a script or using a test framework or something else.
You can probably easily conclude that the absence of checks and statuses likely means that CI isn't being performed (even that can't be said with 100% certainty as an external system may be performing the CI, just not reporting back the status). The presence if checks and statuses means that something happens. But you likely need to dig a bit deeper to classify whether the thing that happens constitutes to CI.
we are a team of 5 people working with microstrategy. We share every role, but we have no worklfow.
Everybody may build or change attributes and change the schema. This leads often to reports not working. Furthermore, there is no "good" documentation. We tried to establish a documentation with sharepoint, but there we also had no workflow.
Originally, we had an old project where for every report all the attributes where constructed newly. So we did not reuse any existing schema object.
Hence, we started a new project. We realized that due to lack of understanding and lack of workflow we make and made a lot of mistakes. We feel that we understand things better slowly (parent child), but the workflow is still horrible.
We have a development project and a lice project, but with the way we are working now, we have a lot of problems. Particularly, the missing version control system is killing us. We perform changes and forget what we did. Hence, we have to use backups, destroying useful work on a given day
So what are best practices to:
* deploy new attributes, facts and reports
* ensure that old reports work after constructing new attributes and facts
* improve documentation
* attributes defined on fact tables and parent-child relationships
Any help is appreciated
MicroStrategy development in a team environment, deploying from development to live, can be very challenging. As you rightly point out, the lack of version control, and unknown interdependencies between objects can cause untold problems. There's no one right answer to this question, but I would suggest the following:
Use all the tools provided by MicroStrategy. When you're deploying from one project to another, don't just drag and drop in Object Manager, create a package. When you deploy that package, make sure you choose to create an undo package, so you can rollback changes if you encounter any problems.
On that note, try to catch these problems in advance. Running Integrity Manager before and after a deployment, even if it's just to generate SQL for the reports, will point out if you've broken anything. On that note:
Create a third environment/project. Call this test/release control, whatever you prefer. Here you can test packages created in Object Manager, to ensure that they have the desired effect, and don't break anything. In effect, this is a dry run for your deployment to live. This environment should be regularly refreshed from live (via project duplication), to make sure it doesn't get in an unexpected state (as the result of a broken Object Manager package import for example).
Over and above that, I can only offer organisational advice. It's not uncommon for one person to take responsibility for schema objects (i.e. facts, attributes, transformations) so that developers don't undo each other's changes. If you have a large project, these objects could be split into functional areas, and individuals assigned.
Documentation is always tricky, but I like to put as much as possible into the object descriptions. This has the advantage of being visible in the Web interface (via tooltips), and included in the automated project documentation, should you choose to generate that. There is obviously the change log functionality for each object, but in my experience, those logs are soon not completed by developers, as saving happens too frequently. Still, if you can get people to populate that, you'd have a head start on understanding the change in your project.
To summarise:
Use Object Manager packages to deploy changes
Test changes with Integrity Manager, to catch any issues as early as possible
Use a release control project/environment, so you're not catching issues in your production environment
Assign responsibility for schema objects to a specific person or persons where possible.
Background:
JIRA offers a single set of statuses for all types of issues in a project.
Problem:
The problem is that the status set for a task is ToDo, InProgress, and Done. While for a UserStory in the same project it might be Designing, Developping, Testing, Releasing, and Done. It can even be different for a bug or an Epic.
Question:
How do you keep track of the workflow of your product and at the same time manage the status of your tasks using the single set of JIRA status.
PS: I know they can be customized for each project, but it doesn't help because you can't customize them for each issue type separately.
I think one of the reasons that JIRA offers the To Do, In Progress, and Done is that these can apply to anything. You either haven't done it, you're doing something, or you finished. That set can apply to any type of item.
That being said, I feel your pain in wanting to have a better view into the true state of an issue. What we have found we use for our OnDemand agile boards is to set up something like the following:
To Do
In Progress
Ready for Review
In Review
Done
For most types of issues, this can work. It adds that bit of extra layer to be able to identify what is ready for testing.
One of the things that is tricky is dependent tasks. For example, I noticed you mentioned "Designing" as a stage, and I'm not sure this makes sense in an agile sense. If the design is emerging from the development, it may be better to allow the design/development to flow within the development team. However, we all know that sometimes you need to get some details ironed out before you can proceed, or there may be some people that need to become involved before a dev can proceed. We made the mistake of trying to turn this into a stage, but what we found was that this was really either a sub-task for part of the team, or an impediment (blocker). By flagging stories, you can identify that a story requires something to be done before the development team can proceed.
If you are using Kanban, and not a Scrum board, the sub-task approach will not be for you. In those cases, you'll just need to make sure you have stages that make sense for all the issues you create. Stages will have to be fairly 'generic'. This sounds bad.
But it is not!
I believe teams generally use the stages for a few reasons:
Checking on status of an iteration
Inform other team members that they can pick up an item
Try to get a visual estimate on how close to Done an issue is.
More stages doesn't necessarily give a better status on an iteration as you really just need to see how many points you've closed and how many are in progress. So, at least for that goal, a more generic set of stages should work.
As for informing team members, too often I've seen teams retreat to the digital board to replace communication with each other. The fewer stages you have, the more you can force your team to talk to each other and work together to get a story to done. Things will work better this way, I guarantee it! Having a bit of a break-down helps, especially if you are working on a lot of items at once or have distributed teams working in different time zones, but keeping it simple is usually better.
Tracking the "how close to Done" is the hardest to do with generic stages. However, the multiple stages can be misleading. An item that is almost all the way across might have a severe bug in it that hasn't been found yet, so no matter how many stages you have your view on this item isn't any more accurate than a single "In Progress" stage. It isn't Done until it's Done :)
This was a long way for me to recommend keeping your workflow simple and letting your team use communication to keep on top of things. Maybe I should have just started with that!
The statuses that are available to each project is determined by the Workflow to which it is assigned. Not only does a workflow define the statuses, but it also defines what statuses you can progress to from a particular status. You can either create your own Workflows or you can download predefined workflows that suite your need.
In order to have separate workflows for different issue types, we need to define a Workflow Scheme:
1- Go to Jira Administration -> Workflow Schemes
2- Edit the Wokflow Scheme that is assigned to your project
3- Click the "Add Workflow" to add a new workflow for the issue types for which you need a different workflow and assign those issue types.
I work in a shop where we maintain numerous .Net projects that require many small changes. We typically get a Service Request from our customer asking for a new feature. We need to ensure that the work we do is checked into TFS and can be related back to the SR in our help desk database, and that the changes to our code can be reviewed in isolation.
There have been a few strategies that we have discussed, but I hope this question isn't considered subjective as I feel there must be a single practice here that we should be employing. TFS has been used primarily as a source control repo for us, but we are looking to leverage more of it.
1) Currently, a developer creates a Task in TFS, and gives it the name of the SR work number. Then, all changes to the codebase are checked-in against that task. I personally am hesitant about this approach as we are co-opting the Task artifact to be used in a way it hasn't been intended for.
2) There has been discussion about branching for each new feature request we receive, and tag the branch with the SR work number. Should we be concerned about the overhead here? My understanding is that branching and merging can lead to complexity.
3) Simply add a comment to the changeset that is prefixed with the SR work item number. This is a simple approach, but when I View History, there doesn't seem to be an easy way to search through the changeset comments for the SR work number.
4) We're not terribly familiar with labelling, but would it be an option? It sounds like we could tag our Team Project with our SR work number once the work has been completed, and that would provide us with the snapshot we would need if we ever needed to refer back to the changes made.
Obviously, if I've missed the boat entirely, I'd be grateful for guidance.
I don't know if you're aware that you can customize TFS work items? You can create a Service Request work item. Make it a kind of Requirement. Make the tasks needed to create the new feature be children of the Service Request work item.
You can then use Branches, but only as a method for isolating the work of one feature request from another. As you check in work to the branch, be certain to associate each check-in with a task. You will be able to track the tasks across changesets and across branches.
As you perform builds, they will be associated to the changesets, and therefore, to the service requests. In the same way, test cases, bugs, and the tasks needed to remediate the bugs will also be associated to the service request. You will be able to track everything that happened with respect to that service request.
I assume you have a separate system for entering Service request and you want to continue using that. I'm also assuming that you are using Agile process template in TFS (http://msdn.microsoft.com/en-us/library/dd997897.aspx) but this should also work if you are using Scrum process template.
I would not suggest creating a custom work-item for Service request but just adding a new field to your user story/bug and name the field "SR work number". Creating custom work items and even adding new fields (adding new field is less painful) is not recommended unless you really need it as it becomes painful when you want to upgrade/migrate your project. You can find out how to customize work-items by going to below link:
http://tedgustaf.com/blog/2011/1/how-to-customize-tfs-2010-work-items-and-workflows/
Based on the info you provided I can suggest following workflow. This might be too much for your needs and if that's the case you can ignore creating user story and bug and directly create tasks.
Workflow:
1) Your helpdesk team creates a Service Request (in a different system) which generates a Service Request number.
2) Helpdek/Product/Dev team decides whether its a new feature or a bug in existing code. Based on that they create a User story(for new feature) or Bug work item in TFS.
3) Tasks are child elements of User story so if you want to break down your user story (feature) into multiple tasks then you can create tasks as child elements to the user story.
4) You enter the Service Request number in the new field you created for it. You can also later use the field for reporting purposes.
5) When developers check-in the code they link it to the appropriate user story/bug/task.
I wouldn't suggest #2, #3 and #4 for the same reasons you mentioned.
Our company is moving over to Jira for all project management and issue resolution
We have a few major uses that i am trying to build templates for. One being a typical issue found and fixed and can easily be handled with a single issue with basically the included jira workflow.
A more complex one is following a Waterfall workflow where Requirements are gathered including an estimate. Then Development kicks off, and in parallel test scripts are made. After Development is done the project is tested and handed off to the client. And finally once all is tested we release the change and re-test. In total I have 30 different steps built across 5 Sub-Tasks (However this is all just mapped out in Visio and not actually in jira yet).
The splitting across Sub-Tasks I hope can accomplish 2 things. First is that we want to track open-close times and efforts (hours works and days needed). And we should have the workflow split to multiple people so the Developer can work while a Tester can build their testing plan. That is able to save a few days, however is not a deal breaker.
So a few questions that I hope can help make this possible, although I am quite new to the various add-ons for Jira, I have no idea if we will get everything we want.
1, Is there an add-on that builds templates of Sub-Tasks, since each Sub-Task needs its own workflow. Currently the rules for Jira is to assign a workflow based on Project+Issue Type. So I believe I can have the proper piece of the workflow assigned to each Sub-Task by creating many Issue Types, like "Custom-Dev-Analsys" for the Sub-Task called Analysis
2, Is it possible to have only 1 or a few of all Sub-Tasks being the "current" one? When the issue starts the first Sub-Task should be the only one worked on, with only 1 of the steps being assigned to someone. After sign-off there should be 2 Sub-Tasks, the Development one and building Test Scripts. But all 5 sub-tasks should not be started since the very beginning, but it seems thats what Jira will do. I have looked at the add-on "Structure" and while that has unlimited hierarchy, I do not think it will let the sub-tasks open up in order. There might be a simple way to make the workflow open the next task (I am very new to workflows and trying to learn as much as possible before messing with our site)
3, If anyone can think of some way to do what I need differently, I am all ears.
Thanks!
I don't know any plugin that does all what asked for, but I had to deal with similar issues, and managed to sort most of them out with the Jira Scripting Suite, but it did require some development (using python).
It's easy to add to your workflow transitions that will create or close a new issue or a new subtask. I use it to create subtasks just by filling some required fields in one of the issue's screens. After the sub-tasks are created, only the automated scripts can close the issue, and that can be done by closing all of the subtasks.
If this kind of solution suits you I will be happy to help with any further inquires.
JIRA doesn't support nested workflows but one useful thing to remember is that if you change the issue type of a JIRA issue, it can have a different workflow. So an issue could start as TEST-123 which is a Requirement. Then after it reaches the end of its workflow it could be Moved to be a Task issue type.
Subtasks should stay as before.