I have a TFS plugin as a part of my application that sends out alerts to a web API URL when anything changes on that TFS 2015 instance. The Web API processes those alerts as required.
Now I recently came to know about the
Web Hooks feature in TFS 2015 which essentially accomplishes something similar.
I'm considering getting rid of the TFS Plugin and switching onto the Web Hooks simply because I will need to maintain one less component. However, reliability is most important to me. So, is there a way to find out if the latter is more reliable than the former, or if it's the other way around?
Also, does TFS give preference to either in terms of execution order? I've been told that the web hooks capture the field values (for a WorkItem) when the event is created. Whereas the plugin retrieves the fields after the event is fired so there might be a small lag time.
Related
In my job we are building Web Apps that rely on a common Enterprise class. This class has a method that sends a request to our server every time the app_start or app_end event triggers so we can monitor the status remotely. But we are now requiring that at least once a day the web app reports its status, a bit like telemetry. I don't know how to accomplish this, so far I have found some options, but some have limitations:
Use hangfire. I don't like this since it requires to setup a Database or add more tables and install a new Nuget package on each project, but could be my last option.
Use a Windows Service that reads databases. This could be less work but it can't access the Web App web.config code
Use a Javascript tasks that sends an AJAX request. This requires to have an open web browser and is a big risk.
I'm looking for a server side approach that could allow to set to trigger an event or function at 1am.
I would got with Hangifire.
It is dead easy to setup and very reliable.
You don't need to setup the database, you might want to check memory storage:
https://github.com/perrich/Hangfire.MemoryStorage
Also check:
What is the equivalent to CRON jobs in ASP.NET? - C#
You can use FluentScheduler instead of Hangfire (it is more lightweight).
Instead of a Javascript task that sends an AJAX request you can use a WebJob or an Azure Function.
I'm working on a POC to automate downstream processes in external systems based on JIRA processes and have hit a wall with the API. It appears to have great integration for pulling data about tickets out of JIRA and for the ability to externally generate tickets into JIRA.
However I don't see how to trigger external calls as a part of my workflows. For example if a ticket should be prevented from being routed to the next stage of a workflow without accessing a database to ensure availability of inventory first how could I do that in JIRA?
Based on attributes in the JIRA ticket upon final completion of the workflow we'd like to send a JMS or REST message or possibly update an external database. Is this possible?
Thanks all in advance for the help!
If you want to do a "before" check, use a Validator on the Workflow Transition.
I strongly suggest deploying the (free) Script Runner add-on. There you can implement a ton of things. For example, you'll get a new validator option "Script Validator", where you can specify a Groovy script that decides if it lets through the transition or aborts it.
In dev environment I am using the ASP.NET configuration tool in Visual Studio to create a few users for testing. As I movel closer to QA and Production, I'm wondering what is the best way for me to automate the creation of a large amount (1000's) of users after application deployment.
I have a csv with all the usernames and passwords, roles etc. and I wan't to avail of the encryption and password salting security that is built in. I do not want to manually "Register" all these users.
I'm just not sure if this is something I can do (or instruct a db admin to perform for me).
Does anyone know of a way to achieve this?
Any assistance would be greatly appreciated.
Regards
The simplest solution would be to set up a "CSV Upload" form. The CSV would be processed by an MVC action calling Membership.CreateUser in a loop.
Probably, the performance of this will be good enough.
There's a few ways that I know of approaching a batch processing problem on an ASP.NET site.
Because of the wonky way an ASP.NET site's application pool can get recycled, batch processing is usually done on an external process.
Windows service
One way is a separate windows service, which gets the new excel and pumps that data in, and has a timer which keeps going around. I've seen this used often, and it is quite a pain, because it takes extra work to make it easily deployable.
Update ASP.Net membership from windows service
CacheItem
Second way is to use CacheItems and their expiration timers to do batch processing, what you do is you define a cache object with a long timer, and when that expires and the Removed-callback gets called, you do your database work. This is good because it deploys with your ASP.NET site, and you have your code in one logical place.
https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
Workflow Foundation
Third way, is to make a workflow foundation service. That service gets a call from your ASP.NET site, which instantiates a WF service, that does some db work with your excel file, and then it goes into a while-loop with a delay of a month in it. This is good, because it is not tied to the lifespan of your ASP.NET application pool - you get more control, and this logic can be separated into a different IIS hosted WCF service.
http://msdn.microsoft.com/en-us/library/dd489452.aspx
Integrating with data is always a pain though, remember that the solution that gives you the least work and least chance of failure when deploying is the best solution.
I know TFS has a web server that gets installed with it, and that's great. I know it integrates very tightly, and very well with Sharepoint, and that's also great.
What I'd like to know though, is since the WSDL's for TFS are public, essentially making the API to send and receive data from it public as well; are there any alternate, non-Microsoft interfaces to TFS that provide most or all of the functionality, with consumer-driven enhancements, such as charting, or reporting solutions not found out of the box?
I've searched the almighty Google and Bing, and they are proving very difficult to find answers from.
You can create your own solution using SharePoint Enterprise edition and a combination of Excel Services reports and SQL Server Reporting Services reports; A SharePoint solution is the closest you'll find to something.
You can use the TFS SDK and object model to create your own application, but most people don't go very deep because Microsoft's Web Access tool is a capable client tool for most teams. There were also major improvements just released in the new TFS 2012. In fact Web Access started out as a 3rd party tool and there are some ways you can extend it.
There is one app I know of off the top of my head that has a web interface to TFS that is very simple; it can be found at http://techdayskanban.codeplex.com
There is also an example of extending the TFS Web Access at http://tfstimesheet.codeplex.com
Codeplex is a good place to check around because it is open source.
A commercial example of a product that extends Web Access can be found at http://urbanturtle.com though It seems you are looking for something more stand-alone.
I have figured out that TFS 2010 has the following web service endpoint
http://tfsservername:8080/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx
Are there ones to get a feed of check-ins, work items and other TFS items?
Update: yes! Visual Studio Online introduced a new REST API, and on-premises installations of TFS 2013 have access to this new API.
In versions of TFS prior to TFS 2013:
tl;dr: Not in any way you're going to want to consume.
Team Foundation Server does expose SOAP web services that the clients use to talk to it. However, it's not something that is publicly documented, it's not supported by Microsoft (meaning they can, and will, change version to version) and, quite frankly, it's remarkably unlikely that the effort required will be worth the result.
Although the web services are well designed, some of the web services require a significant amount of client state. This is particularly true of the work item tracking web services. The clients basically contain an entire "rules engine" for processing and verifying changes to any fields. The client must, basically, be able to understand the process template and process all these state changes before submitting an updated work item back to the server. The server will also run the rules and verify that the client made only legal changes.
The rules engine is not exposed publicly. You would have to reverse engineer it.
This also makes some underlying assumptions like your web services stack can successfully speak NTLM2 and Kerberos properly (most can't, outside of the .NET web services stack, although some an support NTLM version 1 to some degree, which will only give you the illusion that you should be authenticating.)
It's therefore strongly suggested that you just use one of Microsoft's APIs for accessing TFS, either the .NET or the Java SDK.
(I actually worked for a third-party company that successfully wrote a Java front-end to TFS by talking to the web services. It was a fair challenge for us -- especially the work item implementation -- and this was the full-time job for several of us. I wouldn't recommend it as a side project.)
Just like Edward mentioned, the TFS web services aren't meant for public consumption.
On the other hand, you might want to give the "OData Service for Team Foundation Server" a try.
It offers a really nice REST-like interface - thus callable simply by issuing HTTP requests, just like you were willing to do with the web services.
To learn more, check this blog post: http://blogs.msdn.com/b/briankel/archive/2011/10/26/odata-service-for-team-foundation-server-2010-v1.aspx