I am writing a service that integrates Priority with another application. I would like to know if Priority has webhooks or a similar mechanism that would allow my service to be notified when there are changes to entities in Priority.
E.g. when a new customer is created in Priority, my service would like to be notified.
Otherwise what would be your recommended approach?
Thank you.
Currently there are no webhooks support in Priority.
In Priority version 20.0, using REST API, You can retrieve data that have been modified since a certain date. Using $since
Rest API Release Notes (Priority V. 20.0)
Rest API Changes
Reworked text form support. Text will no longer be broken down into lines.
Documents (forms with Business Process Management) now support the use of $since to easily retrieve records that have changed since a given point in time.
Priority can be programmed to do a lot of stuff.
In this case you need to build a customize trigger that will send a notification (json/xml/plain text) to your web service when new customer is created.
It is Proirty programming and not PriorityWebSDK programming: The trigger should be written inside Priority.
Since version 20.1 Priority supports webhooks for the BPM enabled forms.
To define one, first of all you need to create a record in the specialized form at System Management > System Maintenance > Periodic Maintenance > BPM Maintenance > Webhook Definitions.
Then you can use your previously defined webhook in the Business Rule Generator in very similar to SMS/email sending way.
This functionality isn't a part of the basic Priority package and you will need to buy dedicated module in order to enable it.
Related
We had a few cases when:
Someone changes a task group (or build/release/whatever).
Makes some mistake.
Then publishes/saves it.
But doesn't notify anyone that such changes were made.
Some hours later some dependent build breaks because of those changes.
And we have to spend even more time trying to find what and when has changed as it is not often that simple to find out with external task groups.
What we want to have:
Ideally - some approval process for such changes. Kind of like code review, but for task groups/builds.
If not - then at least some way to receive notifications about changes in task groups and etc. we are interested in?
I found neither, and, honestly, doubt that such features are present in the TFS version we use (TFS 2018.2), but perhaps I've missed something.
There isn't any workflow security or approval process for the groups. You could suggest that kind of feature on the developercommunity. Restrict access to edit Task Groups to only those who understand how to bump the Task Group version. That way at least you will keep backward compatibility across your builds unless that explicitly upgrade to that version.
There aren't any built in notifications, but you could create an automated process to send email notifications using PowerShell using the existing API.
Get the Id for the task group using the taskgroups list api
Use the revisions api to get the history _apis/distributedtask/taskgroups/{taskgroupid}/revisions
Send an update for anything that edited today
I am designing a system (stack: MVC 5, EF6, SQL Server) which needs to capture a lot of information about user interaction with various components of the app.
E.g.
How much time a user spend on a particular screen.
What action is the user performing: viewing, editing a page/form
Idle time
Progress in a particular workflow
And show all this information on a Management dashboard which is part of the same web app.
The traditional way of doing this would be to fire a sql query when a certain action happens and save this information in the application database. The thing is that, I don't want to overload the main application server with all these tasks and this approach doesn't seem too robust to me.
I was reading about Application Insights (Telemetry and custom events) and it seems that it should work for my problem statement. The only problem is that it is very tightly coupled with Azure resources and portal dashboard (as per my understanding).
So my question is: Can I use ApplicationInsights package to capture metrics and persist the data in a local SQL database and show it on a custom dashboard?
I read about continuously exporting telemetry information from Azure Storage to Power BI or SQL DB but wont work for me because I cannot use Azure as an intermediary.
https://azure.microsoft.com/en-in/documentation/articles/app-insights-export-telemetry/
Would really appreciate some guidance on this. Thanks.
You can use PowerBI dashboards, with direct integration to Application Insights, specifically, with Analytics queries you likely may use in this scenario.
Also, you can consider using Application Insights API (https://dev.applicationinsights.io/) to achieve this directly, including integration with some popular dashboards. Note that API is now in early preview, so we may introduce some changes, but the overall shape should be stable.
I am also curious what prevents you from using Azure - we'd like to learn more about it. Please be aware of the fact that Application Insights stores it data in Azure
For the specific case when you want to use just Application Insights SDK, while storing and analyzing the data "locally" in your tool of choice - this is also possible. (Note: in this case you only benefit from App Insights SDK and schema, leave the door open for future possibility to use full App Insights). To achieve that, you can consider implementing a custom telemetry channel - see here for some additional information: http://apmtips.com/blog/2016/01/31/telemetry-channels-update
While implementing this approach, you should you should be mindful about the volumes - I would advocate for decoupling it through some form of a queue mechanism, makes it easier to protect your app, balance the load and also monitor ...
New to TFS configuration/manipulation and looking to be pointed in the right direction thanks.
Our bug reports are often posted with minimal information and its often necessary to call the creator to get clarification. It would be beneficial if we could display the phone number alongside the creators name. Is it possible to pull this info out of the directory ?
I cannot think of a simple way of doing it, apart from writing code. I can think of these techniques:
pulling data from Active Directory and updating work items;
a custom control that query AD (via a REST web service) just in time
This latter can evolve to became a 2015 extension
I am going to develop an iOS app for a web application. (The web app uses code igniter)
I am going to create an API Service that the iOS app will consume.
I am thinking of creating an api version, so when the web api changes, the iOS app will know.
Concerns:
iOS app will need to be updated when web application api changes (unless I keep legacy api available..Is this a good option)
If iOS app is updated when web app api is NOT updated this will cause a problem too
Should my iOS app specify the version of the api it requires?
If iOS app api is less than web api: Display Message: Please update iOS app
If iOS app api is greater than web api: Display Message: Please update web app
Is this best practice?
Should I make an api class for every version and extend the previous version and override methods when they change?
Example
ApiV1 extends CI_Controller
{
function list_customers(){//Code}
function saveSale() {//Code}
}
ApiV2 extends ApiV1
{
function saveSale()
{
//New way of saving sale
}
}
Also what happens if I make a change to the database structure where the v1 api will no longer work? (Example, changed the name of a database table?)
In general, you want to create a fairly loose coupling between your service API and your client. As a rule, there will be multiple versions of the client always floating around in the wild, and you want to force upgrades on users as rarely as possible.
A full rev of an API version is actually somewhat rare in web services, and usually only corresponds to significant changes to the data model, security model, etc. Allowing multiple versions to coexist may require some extra work on the service, but can be worth it to allow existing clients to keep working.
To that end, think carefully in the design up front about the "model" you're using as an abstract entity independent of the current client UI needs. (If you want more specific thinking around your particular case, you may wish to post a separate question about modeling your needs.) But don't worry too much about solving all of the needs forever in advance, because requirements will inevitably change.
Once you've done this, do prepare for the future by building some notion of versioning into the service API. Some things to consider:
An explicit version as part of the URL scheme or specified initially during e.g. auth handshake. This is a way to cleanly namespacing what the client accesses. (The former would result in explicit URL routing on the service, the latter would require more gymnastics to route after cracking an auth token.)
A known error response that means "this API call is obsolete", which an earlier client can recognize to tell the user that their client requires an update
On the service, your design can be as explicit as you note, with a controller with method overrides, but at a little higher level: the saveSale method is somewhat unlikely to behave very differently between versions. It would seem more likely to have a saveSale method in V1 that does the baseline thing, and then maybe e.g. saves some extra bit of data in V2. When that happens, the code might just have conditional branching if that extra bit of data is present. All of this is another way of saying that a service API doesn't actually change incompatibly that often. list_customers could return more information over time. That doesn't necessarily mean that your API needs a new version or that old clients shouldn't just ignore any extra information they don't need.
Re: your final question about database table names. Those may change internally, but you aren't required to map those explicitly to what the client sees. An API is a stable interface that should ideally hide the implementation details of your ever-evolving service.
You'll choose to rev the API when, as a whole, you decide that the overall picture of what the API needs to do is significantly changed enough that it cannot peacefully serve the needs of existing clients. You'll choose to deprecate and obsolete certain client versions when you decide that maintaining support for them on the service is causing you more headache than the install base is worth (a very business/case specific issue).
Good luck.
I don't know if having your iOS app specify the version of the api it requires is good practice but, I would think it is a safe play; one concern though, if you frequently update your api then it won't be long before it becomes a hassle/anoying having to frequently update the app.
I would keep legacy method name(s) and add method(s) with a different name to avoid users having to update to new version of the app when you change the web api.
I would not create an api class for every version to extend the previous version of the api.
I would say changing the database structure would require changing/updating your api, unless you also want to keep legacy version of your table name or definition or data, which it is not feasible/practical/convenient in most instances/situations. In this case you want your users to update to the new app and api.
Look at this answer that points to a presentation of API design principles and practices.
I do not know as to what best practice, however I would definitely recommend that your iOS app keep track of what version of your API it is looking for, and specifically request that version. For instance, a URL of '/api/v1/....'. This way When you update your API, you can simply up it to a different version ('/api/v2/...', and leave v1 alone for the iOS app to consume. Obviously you should display a message to the iOS user to upgrade (perhaps a meta field in your response) when a newer version exists.
This approach should allow you to continue development on your API without cutting off people who haven't been able to upgrade their app.
Update
Just one more thing; if you make a change that will make a previous version inoperable (such as changing table names, schema, etc), you should have a status code for that that your iOS app will understand. Something associated with the message 'This API version has been retired. You must update'.
I would also recommend a similar header (or something) when an API is deprecated (ie, a new version exists). Obviously continue to provided the requested information/actions, however a warning that the version is not supported anymore and that they should upgrade (or even triggering something in your app to upgrade) can be helpful.
I'm looking for a simple solution for support case management. The final nominees are Fogbugz and the open source OTRS.
Hai ofer,
I have used fogbugz for all my web application test cases... It has good version control which be very useful to graph your cases from the day of first test to the latest version....
Individual logins from admin and users would be best suited for assigning,reopening and closing cases....
FogBugz makes it simple to enter bug reports and other types of cases.
Also a FogBugz user. I use it for:
Integrating with SVN for Bugz update assignment to cases
Have an email inbox set up (cases#xxx/fogbugz.com) to allow end-users to submit email (either via their email client or through automation)
I use their API to allow bug submissions through our UI
Managing my team. I categoriese something as "Design", and it goes to our designer
Along with the excellent filtering of cases which allows you to get a snapshot based on any criteria you can think of. It's also really good at concurrency, so if changes occur on a ticket while you're looking at it, you are notified.