Within my LUIS model, I have a hierarchy entity type. When I use the test console, it is recognized as Parent::Child.
However, when I make the rest call, I only receive the Parent.
I have verified that the active model is published to staging and that I am calling against the staging server.
Related
I am writing a Page in DialogFlow CX Node js API. The page have a parameter that uses system entities for example #sys.any.
So publishing such information require ids of the resources from dialogFlow. I can use a custom entity Type by following the pattern: projects/<projectId>/locations/<location>/agents/<agentId>/entityType/<entityTypeId>.
But for System entity I use the pattern :
projects/<projectId>/locations/<location>/agents/<agentId>/entityType/#sys.entityname.
Eventually gets an ERROR:
Entity type 'projects/chatbot-dev-356403/locations/europe-west2/agents/1cd671ea-1ec6-4b3f-90fa-4c754d0f9f47/entityTypes/#sys.any' of form parameter 'Improve' does not exist in the agent.
How to call that system resource (entity) through API?
If I'm wrinting BDD style tests. What would be better practise:
When User A creates new record
Then DB contain correct record
or
When User A creates new record
Then User A can get his new record by some API request
And Admin-user can get this new record by another API request
So should I check internal state of DB or just use API and consider application + DB as a black box?
You should test your application as much as possible using the APIs, as it gives the actual behaviour of your application. In your case, it would be
When User A creates new record
Then User A can get his new record by
some API request
And Admin-user can get this new record by another API
request
Reason being:
By using the Admin API, you are making sure the record is in database and the Admin API behaves as expected
In the future, if your DB changes, which is internal to your application, but the API's behaviour doesn't change then your BDD would work without any issues. In other words, if the devs decide to change DB and not the API, the business service which uses the API is not impacted
If you test only DB, but the Admin API changes, your scenario would pass but the Business service, which uses the Admin API, would fail
The only scenario, you would check the record in DB directly without an API is, when there is no API to verify the record. You shouldn't develop an API purely for BDD. The Admin API should be used in a business service and if this is not the case, you can check the DB record directly (your 1st option).
PS: We have developed a product NoCodeBDD. As the name implies, you can automate BDD without any code using NoCodeBDD. I would love to get some feedback from the community. You can download a free version from www.nocodebdd.com/download
Generally the thing that creates should be the thing that validates. So
if a user (human interacting with a UI) creates
then a user interacting with the UI would validate by viewing the created thing.
if an api client creates
then the api client would validate by examine the response from the create call
additionally the api client could get the thing created using a link in the response
In both cases I would only consider validating via the DB as a temporary measure whilst you are working on the scenario
I am exploring Composer. I already use bot-framework c# model in Azure that connects with LUIS. We developed a one step FAQ bot (not multi-turn conversations) with only one main dialog. We used to extract the Luis intent and score whenever users type a text. We get answer from a SharePoint list for FAQs by passing the identified LUIS Intent as a column filter.
Is it possible to do the same in Composer to get the intent identified and score for each input we get from user.?
Also, instead of training the LU model in composer, can we train the utterances in the LUIS portal and consume the same intent/score in composer?
Yes it is possible to use Luis inside Bot Framework Composer to recognize intents and do entity extractions. Bot Framework Composer allows you to put conditions on the recognized intents which you can use to make sure the next steps only fire when the score is >= x.
You can see how to use this in action and how the scoring works here (starting at 27:38):
https://youtu.be/ZNcfIgO8biw?t=1658
You can still make changes in the Luis portal, but at this time this is not recommended as your changes will be overwritten the next time you publish to Luis via Bot Framework Composer. If you make changes in the Luis portal directly, make sure to export the .lu and re-integrate your Luis model in Bot Framework Composer to not lose your changes.
I'm working on an event sourced application following DDD and CQRS principles, which allows the posting of ads to sell goods.
There's one specific invariant that i'm trying to model which would seem to involve a bulk update of AR's, and I don't really know how to go about it.
The invariant is as such:
A Member can post an ad
A Member could be banned by an Admin
If a Member is banned, his ads must be suspended
for the purposes of the discussion, an Ad needs to have a status, as a Member can buy an item by clicking on an ad, so it's important to know if an ad is active.
I have designed my aggregate roots as such:
Member
Ad
Order
A Member can be a buyer or a seller, depending on the context, so I decorate the member object as needed.
When ads are published, they are of course inserted in a read model.
Now, when a Member is banned, there's an event associated that the Member AR triggers.
MemberWasBanned (MemberId)
My question is how do I go about finding every Ad that the member owns, and suspend them?
While I could rely on the member status for a buy transaction, it's important that the Ad tracks its status as there are other similar operations that could trigger the sending of an email for instance to the member indicating that his ads were suspended for such or such reason.
So my best approach after a lot of thinking is to create a long running process, in which I create a handler for MemberWasBanned, then go look for his active ads in the read model, and issue commands to suspend them one by one.
Am I missing something? I thought of using a process manager, but read that you shouldn't access the read side from a PM. In any case a PM in most cases determines the command sent to ONE AR.
Am I missing something?
If you have a messaging mechanism, maybe you can "explode" the MemberWasBanned event.
Publish the MemberWasBanned (or equivalent) event through your messaging pipeline, and subscribe to it from the context that handles ads. When this event is received in your messaging mechanism, you can explode it into multiple DisableAd events that will also be sent through your messaging system, each of them targetting one current ad of the banned member.
Each of these events, then, will only write on a single Aggregate (each ad, disabling it) when they're processed by the messaging mechanism.
Concurrently, the banned user will prevent further ads from being inserted, so you will be safe on that end as well.
I have gone through this great tutorial: http://www.cqrs.nu/tutorial/cs/01-design and trying to do my app same way.
According to my previous questions I know, that what is entity in one BC can be represented as value object containing identifier of entity in other BC and optionally any other parameter. (I put those identifiers to Core BC.)
Now, let's say I have two BC: PlansEditor and Subscribing.
In PlansEditor, given there is Editor (person with role), when he creates Plan with some params like frequency and vip, then Plan is created.
In Subscribing, given there is Customer and some available Plans, when customer subscribes to a Plan, then Subscription is created.
Plans here could be just VO with frequency and VIP parameters, because Subscription needs just them (to protect invariants). But customer clicks to subscribe to a plan and request with id of plan is sent.
So I start my BC lifecycle with id of customer and id of plan he subscribed to. I need to load/create that Plan "value object" (which is really entity in PlansEditor BC) by given identifier somewhere.
Where and how should I acquire that Plan VO in Subscribing BC?
I thought in application layer through Event Repository - to be able to send SubscribeCustomerToPlanCommand(Customer, Plan) containing this value object. But Subscribing BC would then need to know that Plan as entity in PlansEditor exists in order to load it and translate it to Plan as VO, which is unacceptable - one BC would need other to function properly.
Or should I just get informations needed to create Plan VO from some read model and do that in application layer, is that convenient? Or how and where? :)
As far as I can tell Plan wouldn't be a VO in either contexts. It's not because one BC has the authority on an entity's life cycle that the entity becomes a VO in other contexts (it could).
If the downstream context needs to stay aware of the lifecycle of an entity in a remote context then this entity should probably be modeled as an entity in the downstream context as well.
For instance, I suppose that Plans can be deactivated at some point that and it wouldn't make sense to allow subscribing to these? That would be a good indicator that Plan is not a simple value in the Subscribing context.
There are multiple strategies when it comes to BCs integration, but if you favor availability over consistency then messaging is most likely the better option. The upstream context would publish events on a messaging infrastructure and these would get consumed by the downstream context, allowing it to keep it's local copy of the entity state in sync.
"BC would then need to know that Plan as entity in PlansEditor exists
in order to load it and translate it to Plan as VO, which is
unacceptable - one BC would need other to function properly"
Any integration strategy will require some level of coupling, but that coupling should be abstracted away in an anti-corruption layer.