I built an oData service that delivers two or more records from a database table.
When testing it with /IWFND/GW_CLIENT it works great and I get the information I need.
But when I bind it to a StandardList item which is defined as template, then I only get two List Items (which is correct because the oData Service delivers two records) but they have the same value which is not correct because the value should be different.
I'll add some screenshots for better understanding.
Maybe someone can tell me why the list is not display the correct items.
Thanks
Started App view
GW-Client result
This is because you have oData entity keys which have same values (Mandt='200',Kunnr='10') for both the records. This is the reason for the repeated values. You should have unique key values such that each entry is uniquely identifiable.
To fix this, you should keep properties which have unique values as keys or add multiple properties as keys in your gateway service implementation.
Related
I am establishing two entities in my Dialogflow CX agent:
the first one, called "id" contains some numeric IDs that exist in my domain: e.g. 29042, 29145, 28248, ...
the second one, "wrongId", is defined by a regex that is supposed to capture all numeric sequences similar to the previous entities: \d{5,6}
These two entities are used in different phrases of the same intent.
The goal is to make the agent behavior in a certain way if the numeric ID inserted by the user exists; otherwise, the agent will say that such ID does not exist. For this purpose, I created two different routes. The first one is activated when the first entity is matched; the second one is activated when the regex entity is matched.
Since routes are evaluated in the order they are presented, I would expect that if the user inserted a valid ID, the first route would be activated; if the user inserted an ID that does not exist, then the first route would be discarded and the second one will be activated.
However, I noticed that the second route is always activated, as if the regex entity is always preferred to the regular one when Dialogflow parses the entities in an intent.
Can anyone confirm this behavior, or otherwise point to any mistake I am making?
According to your description above, the entity "id" and the entity "wrongId" have overlapping values. Specifically, regular expression \d{5,6} can match all examples you provided for the entity "id".
Here's a screenshot from https://regex101.com/:
That is, when you input a correct id, either one or the other entity can be matched.
Using entities with competing values is against agent design best practices. Avoiding to use conflicting (also referred to as competing or ambiguous) training data when designing your agent will help you avoid conflicts at runtime.
If you have a small number of correct id's, you could add them as entity exclusions to the "wrongId" entity.
Another approach could be to match both correct and wrong id's with the same (broader) entity and validate collected values against your id's database in the backend.
Can I add an unique custom field inside a work item.
So when a new work item is added, a validation error occurs if a previously added work item already contain a that value.
I've tried inside the "Rule" section of work item customization, but without success
There is no built-in rule to enforce uniqueness. The only field that is guaranteed to be unique is the work item ID.
It is possible to create a custom control that uses the REST API to query whether the contents of a field are unique and have it enforce that uniqueness. But that has a few caveats. The rule will only be enforced in the UI, other experiences (like bulk changes, excel etc) won't triggr this validation. Direct manipulation through he REST API won't either. And I would expect concurrency problems when you venture in this direction.
I'm rewriting an API to be more RESTful, but I'm struggling with a design issue. I'll explain the situation first and then my question.
SITUATION:
I have two sets resources users and items. Each user has a list of item, so the resource path would like something like this:
api/v1/users/{userId}/items
Also each user has an isPrimary property, but only one user can be primary at a time. This means that if I want to get the primary user you'd do something like this:
api/v1/users?isPrimary=true
This should return a single "primary" user.
I have client of my API that wants to get the items of the primary user, but can't make two API calls (one to get the primary user and the second to get the items of the user, using the userId). Instead the client would like to make a single API call.
QUESTION:
How should I got about designing an API that fetches the items of a single user in only one API call when all the client has is the isPrimary query parameter for the user?
MY THOUGHTS:
I think I have a some options:
Option 1) api/v1/users?isPrimary=true will return the list of items along with the user data.
I don't like this one, because I have other API clients that call api/v1/users or api/v1/users?isPrimary=true to only get and parse through user data NOT item data. A user can have thousands of items, so returning those items every time would be taxing on both the client and the service.
Option 2) api/v1/users/items?isPrimary=true
I also don't like this because it's ugly and not really RESTful since there is not {userId} in the path and isPrimary isn't a property of items.
Option 3) api/v1/users?isPrimary=true&isShowingItems=true
This is like the first one, but I use another query parameter to flag whether or not to show the items belonging to the user in the response. The problem is that the query parameter is misleading because there is no isShowingItems property associated with a user.
Any help that you all could provide will be greatly appreciated. Thanks in advance.
There's no real standard solution for this, and all of your solutions are in my mind valid. So my answer will be a bit subjective.
Have you looked at HAL for your API format? HAL has a standard way to embed data from one resources into another (using _embedded) and it sounds like a pretty valid use-case for this.
The server can decide whether to embed the items based on a number of criteria, but one cheap solution might be to just add a query parameter like ?embed=items
Even if you don't use HAL, conceptually you could still copy this behavior similarly. Or maybe you only use _embedded. At least it's re-using an existing idea over building something new.
Aside from that practical solution, there is nothing in un-RESTful about exposing data at multiple endpoints. So if you created a resource like:
/v1/primary-user-with-items
Then this might be ugly and inconsistent with the rest of your API, but not inherently
'not RESTful' (sorry for the double negative).
You could include a List<User.Fieldset> parameter called fieldsets, and then include things if they are specified in fieldsets. This has the benefit that you can reuse the pattern by adding fieldsets onto any object in your API that has fields you might wish to include.
api/v1/users?isPrimary=true&fieldsets=items
I am to a fair degree familiar with Sails and Waterline.
Situation:
We have a Model Playlist with a many-to-many association to the Model Song on sails-mongo.
When we query for all playlists, we do not want to sideload all associated songs, we just need the ids of the associated songs so that we can load them lazily later.
When we do a populate (with Ember blueprints: populateEach()) we of course get the ids, but it takes around 1s for loading all the Playlists.
Without populate it is just around 50ms.
Complication:
After getting the results with query.exec WITHOUT populate, the ids of the associated songs are not included and not sent back to the requester.
But I can log the ids of associated records to the console via iterating over Object.keys(matchingRecord).
I can set them to a new property of the matchingRecord, all without populating.
However, I cannot explicitly set them to their property name.
Using the original property name is required for the interaction with the Ember frontend.
I tried to mess around with Object.defineProperty - no success. I guess the set/get functions are overwritten to prevent that.
Questions:
How can I make those id arrays of visible/prevent that they are hidden/removed?
Are there any other ideas from your side to maneuver around this issue?
Thank you,
Manuel
Recently I learned hbase coprocessor, I used endpoint to accumulate one column of hbase table.For example, the hbase table named "pendings",its family is "asset", I accumulate all the value of "asset:amount". The table has other columns,such as "asset:customer_name". The first thing I want to do is accumulate the the value of "asset:amount" group by "asset:customer_name". But I found there is not API for groupby, or I did not find it. Do you know how to implement GROUPBY or how to use the API that HBASE provides?
You should use an endpoint to do this work.
You have a sum example in this article: https://blogs.apache.org/hbase/entry/coprocessor_introduction.
What you basically need to add is to append your row key and the customer name to form your new key "MyKey". You should keep a variable of the last seen MyKey and when the current MyKey is different from the previous one, you should emit the previous one along with its sum and overwrite the previous MyKey to the current one.
You have to make sure to perform the aggregation on the client side as it is done in the example provided in the URL because you may have a customer at the edges of two different regions.
Using endpoint coprocessor can make it. All you should do is that : first define related interface(reduce) protocol extends CoprocessorPotocol, then make an implementation of it, lastly code the client-side logic.