How do I list all the agents which are used in a specific environment of a Udeploy application?
The resources within the application environment may have hierarchical relationship with an agent at the leaf level of the resource structure.
I need to list the agents only.
Please note that the getEnvironmentBaseResource gives me only the name of the top most resource layer, but it does not list the entire resource hierarchy till the agents.
You should make a nested call.
First get all environments within the application, with:
getEnvironmentsInApplication
And then, get all base resources for an environment with getEnvironmentBaseResources
After that you may parse the response with groovy to get and manipulate the json
Related
I know one can use REST API to query Pipeline activities but is there anyway to query Pipeline components ( i.e, listing of linked services, sources, sinks, parameters, etc.)
Right now I'm manually recording all the components I see in the pipeline and querying these components would make this listing faster and more accurate
enter image description here
Thanks, Jeannie
I haven't found a way to get all the components of a pipeline directly. If the information you want to obtain is defined in the YAML file, you cannot directly obtain it, you may need to parse the YAML file to obtain it.
If the information you want to get is defined on the UI, such as variables, you can get it through the REST API Definitions - Get. And you can get the resources of the pipeline through Resources - List.
Say I have an API that (along with other entities) deals with tasks. My endpoints would look something like
GET /api/tasks //List all tasks
POST /api/tasks //Create a new task
GET /api/task/1 //Fetch a single task
PUT /api/task/1 //Update a single Tasks
GET /api/task/1/comments //Get the comments of task 1
I also need a few subsets of Task data which has an entirely different formats:
user-tasks, tasks for a user but shaped according to schedule.
sync-data, all tasks that need to be sent to an external system with special references
I can see the user data could exist off the user hierarchy such as
GET /api/user/1/tasks //tasks for this user with dedicated
But what of sync-data? Should this fall under the tasks heirarchy or under the system it's intended for such as
GET /api/ExternalSystemA/tasks //tasks for synchronization
REST doesn't care what spelling conventions you use for your URI. Any spellings that are consistent with the production rules in RFC 3986 are fine.
Relative resolution provides a standardized mechanism for computing a new URI from a context and a relative reference. Designing your hierarchy so that you can take advantage of that is, in some cases, a really good idea.
Otherwise, it is a lot like choosing a variable name - the machine doesn't care, so you just want to choose spellings that are satisfactory for other human beings; in other words, making sure that you are consistent with local conventions.
I am trying to model a Call Center with Chat communication and need your thoughts on this scenario. Real world scenario is that Customer Service Representatives[CSR] in Chat Call Center can service multiple customer chats at same time based on their capacity[integer value 1,2...]
"Chat" Agent [source]
"ChatAgent" resource unit with int parameters totalCapacity[default=3]
Using a service, incoming "Chat" from source seizes a "ChatAgent" from a resourcePool[with resourceUnit "ChatAgent"]. In this model, a "ChatAgent" accepts only 1 "Chat" inside the service block.
ResourcePool
On seize: unit.totalCapacity--;
On release: unit.totalCapacity++;
But I couldn't model a scenario where 1 "ChatAgent" can service multiple customer "Chats" at a time based on their totalCapacity like in a real chat call center.
Please advise on how I can configure this multiple agents to 1 resource seize/delay.
Updated Model
Updated ChatAgent Resource Structure
Thanks,
Shiva
Many ways of doing this, but the first thing that comes to mind is NOT to use ChatAgent as a resource (at least not the kind you use on a service block) because chats can come at any given time, and you can't have a resource taking many different agents that come at different times through the service block...
Instead you can use the following structure in the chatAgent:
The capacity of the resource will define how many agents can enter the restrictedArea block... This structure will exist inside your chatAgent resource.
Your main agent will have the following structure:
when the chat waits for an available chatAgent, if a chatAgent is available by doing:
chatAgent.beginService.entitiesInside() < chatAgent.capacity
These are the most important details to make it work... now you have to build the model properly.
The objective that I have is to run multiple applications with some metadata embedded into applications/services so that I could query applications/services using the metadata. Is this possible?
I was looking at the following post and the answer hints at this possibility, but no specific details on how to achieve the result.
The primary piece of "metadata" you get is the service/application instance name. That's what I talked about in my other post. The way that works is by creating each service/application instance with a name that contains some information clients can use when resolving them. Clients can then query Service Fabric for named application/service instances and connect to a specific one. A service/application instance name is URI, so you can use a path hierarchy to categorize information.
Continuing with the audio/video example: Let's extend that example so we have an application that can perform specific tasks for specific media formats for audio or video. Each combination of task + media format is a unique named service instance, resulting in a deployment that looks something like this:
Application:
fabric:/avapp
Services:
fabric:/avapp/video/encoding/mp4
fabric:/avapp/video/encoding/h264
fabric:/avapp/video/captioning/english
fabric:/avapp/video/captioning/czech
fabric:/avapp/audio/encoding/aac
fabric:/avapp/audio/encoding/mp3
etc.
Now clients can query Service Fabric to discover what services are available:
FabricClient fabricClient = new FabricClient();
System.Fabric.Query.ServiceList services = await fabricClient.QueryManager.GetServiceListAsync(new Uri("fabric:/avapp"));
Then you can simply query the list of services with LINQ. For example, if I want to see all services that do video encoding:
services.Where(x => x.ServiceName.AbsolutePath.Contains("video/encoding"));
And then you can resolve an address for a specific service to connect to it:
ServicePartitionResolver resolver = ServicePartitionResolver.GetDefault();
ResolvedServicePartition servicePartition = await resolver.ResolveAsync(new Uri("fabric:/avapp/video/encoding/h264"), new ServicePartitionKey(1), cancellationToken);
ResolvedServiceEndpoint endpoint = servicePartition.GetEndpoint();
There's a bit more to the address resolution part (see here), but that's the general idea.
Application instances also allow you to set custom application parameters (key-value pairs) that can be set per instance at creation time. They don't show up in the application name, but you get that information back when you ask Service Fabric for a list of running application instances. That can potentially also be used as metadata by clients when they need to decide what application to connect to.
Update: More info on application instance parameters:
When you create a new application instance you can supply a set of key-value pairs in the application description. Then when you query Service Fabric for application instances you get back a list of Application result objects that have said parameters. This also shows up in Visual Studio, in your application project, where you have environment-specific application parameter files. Visual Studio extracts those key-value pairs from the XML files and uses them in the application description when it creates an instance of your application.
It's common to nest resources in a RESTful API. For example, to retrieve the employees in company having ID=5:
GET /companies/5/employees
Is it also generally acceptable in a REST design to put resources in a common "directory" where they don't really belong-to a common parent resource instance? This is more of a "is-a" relationship, where I think the typical nested structure has the nested resources in a "belongs-to" relationship.
For example, is it acceptable to group two different resources (internal agents, external agents) like follows? In this case the agents part of the path is a category that describes its descendants but isn't really a parent resource.
GET /agents/internal
GET /agents/external
There are no plans to add any resources using the /agents path; it is solely for grouping purposes.
Or is that to be avoided for something like this?
GET /internal-agents
GET /external-agents
I feel like the second option is more correct, but there is an aesthetic to the first option that that I like.
Given that you have some agents which can be internal or external:
/agents/internal is a terrible idea breaking URL consistency
/internal-agents is a valid idea but beware of drawbacks
A filter could be better for this use case: GET /agents?status=internal
/agents/internal is a terrible idea breaking URL consistency
Having /agents/internal is a terrible idea, it MUST not be used as it will lead to inconsistent URLs in your API which will not be easily understand by humans but also programs.
The best pattern for REST URL (exluding domain and versioning matters) is this one: /resources/{resouce id}/sub-resources/{sub-resource id}// No more than 2 levels should be allowed.
Your first example /companies/5/employees is a perfect good example.
Adding a /agents/internal URL will make your API's URLs inconsistent and difficult to understand for humans but also programs. You can end having GET /agents/2 which return agent with id 2 and also GET /agents/internal which return a list of internal agents. Same URL structure but different meanings.
Using a consistent structure for URL helps to understand the semantic without even knowing what an API does.
/internal-agents is a valid idea but beware of drawbacks
Your idea of having two specific resources internal-agents and external-agents is valid.
But it can have some drawbacks depending on the exact use case:
if you add more status, like partner for example, you'll have to add a new resource partner-agents
if a consumer want to retrieve both type it'll have to make to calls or you'll have to create a /agents resource
A filter could be better for this use case: GET /agents?status=internal
A third idea would be to consider internal and external as filter on some status on /agents resource.
GET /agents returns all agents (internal + external)
GET /agents/2 returns agent with id 2
GET /agents?status=internal returns agents with internal status
GET /agents?status=external returns agents with external status
And if you add a new status like partner:
GET /agents returns all agents (internal + external + new partner status)
GET /agents/2 still returns agent with id 2
GET /agents?status=internal still returns agents with internal status
GET /agents?status=external still returns agents with external status
GET /agents?status=partner returns agents with new partner status
GET /agents?status=internal,partner returns agents with internal or partner status
Choosing between filter and specific resources is only a metter of context.
The only thing to keep in mind is to ensure URLs consistency.