In case I am processing an inbound DESADV that has only the Receiver Qualifier ZZ:
UNB+UNOA:1+SUPPLIER-DESADV+OURCODE-UTOPIA4:ZZ+...
There is no Supplier Qualifier
How do I configure my Integration Account (Agreement or Partner) to support the lack of a Supplier Qualifier? Do I inject on before my Decode Action in the Logic App?
What are the techniques others are using around this?
I was able to get this working with the Edit As Json feature and then deleting the qualifier, so that in the Agreement my guestIdentity is:
'guestIdentity': {
'value': 'SUPPLIER-DESADV'
}
That is, I deleted the qualifier property. This was also the advice from Microsoft.
Related
I'm using Azure App Insights to track exceptions in a React app. As stated in the docs and some other tutorials, thrown exceptions are automatically collected by app insights React SDK, which is wonderful.
However, we want app insights to collect exactly in which error boundary a particular error occurred, but automatically reported error boundary exceptions don't have this information. This makes it hard to decode where exactly are errors in the production build.
Is there a way that allow us to define a custom property in error boundary via props which tells where this error boundary belongs to, and let app insights automatically pick it up when reporting the exception?
Thanks in advance.
Is there a way that allow us to define a custom property in error boundary via props which tells where this error boundary belongs to, and let app insights automatically pick it up when reporting the exception?
As suggested by MSNev, adding gist as a community wiki answer to help community members who might face a similar issue.
As per AppInsightsErrorBoundary.tsx, ErrorInfo details are passed as additional properties to the trackException() call, so they should be available as part of the additional properties in the portal.
You can also use a telemetry initializer to intercept the event before it's sent to move/set additional properties on the event.
var telemetryInitializer = (envelope) => {
envelope.tags["ai.cloud.role"] = "your role name";
envelope.tags["ai.cloud.roleInstance"] = "your role instance";
}
appInsights.addTelemetryInitializer(telemetryInitializer);
Updated answer:
As per comment by Pavindu, this issue has been resolved by passing document.title to the exception data packet in the telemetry initialiser.
I'm trying to write a custom connector Swagger file for Logic Apps and am having problems. The API I want to connect to only accepts OData queries so all my parameters are asking for $filter and the user has to type in Name eq 'Name' and Id eq 1. Is there a way to make this prettier and just ask them for the parameters directly?
I tried just adding them in (Name, Id, Active) but it puts them in the url like ?Name=. Not in the OData syntax. Is there any way to do what I want to do?
The custom connectors are designed to work as interfaces to existing REST APIs and the UI is more of a 1-1 mapping of their specification.
AFAIK, there is no way to direct customize how the connectors work but you could achieve it by proxy request through your own service.
You simply need a service which accepts requests the way you want and translate them accordingly for the actual service.
Azure API Management is probably the best candidate for this. As a bonus, once you have the APIs you need designed, you get an OpenAPI spec that you could use for the custom connector.
Depending on your expected load, you might have to use its Consumption Tier but do note that its currently in preview.
The alternatives could be having your own API hosted on Azure App Service or Azure Functions instead (or even Functions Proxies), again depending on your expected load.
PS: The downside of doing this is the obvious maintenance that you would have to uptake in case your requirements change and/or the backend API changes.
In OSB Layer when the endpoint uri is changed, I need to alert the core group that the endpoint has changed and to review it. I tried SLA Alert rules but it does not have options for it. My question is, the endpoint uri should be saved somewhere in the underlying database. If so what is the schema and the table name to query it.
URI or in fact any other part of OSB artifact is not stored in relational database but rather kept in memory in it's original XML structure. It can be only accessed thru dedicated session management API. Interfaces you will need to use are part o com.bea.wli.sb.management.configuration and com.bea.wli.sb.management.query packages. Unfortunately it is not as straightforward as it sounds, in short, to extract URI information you will need to:
Create session instance(SessionManagementMBean)
Obtain ALSBConfigurationMBean instance that operates on SessionManagementMBean
Create Query object instance(BusinessServiceQuery) an run it on ALSBConfigurationMBean to get ref object to osb artifact of your interest
Invoke getServiceDefinition on your ref object to get XML service
definition
Extract URI from XML service definition with XPath
Downside of this approach is that you are basically pooling configuration each time you want to check if anything has changed.
More information including JAVA/WLST examples can be found in Oracle Fusion Middleware Java API Reference for Oracle Service Bus
There is also a good blog post describing OSB customization with WLST ALSB/OSB customization using WLST
The information about services and all its properties can be obtained via Java API. The API documentation contains sample code, so you can get it up and running quite quickly, see the Querying resources paragraph when following the given link.
We use the API to read the service (both proxy and business) configuration and for simple management.
As long as you only read the properties you do not need to handle management sessions. Once you change the values, you need to start a session and activate it once you are done -- a very similar approach to Service bus console.
I subscribe Aws Iot topic;
12345678/state
I try to write a rule to get this topic's payload at
12345678/shadow/update
I have written my rule by following these steps;
My query string is
SELECT * FROM '+/state'
My action is republishing everything without changing to other topic like this below
$$aws/things/${topic(1)}/shadow/update
When i write some static data instead of topic(1) function like "test", it works. However, i couldn't get topic name dynamically. There is no suitable document explaining how can achieve getting this topic name.
What is the right way to get topic name which is in my case "12345678"?
Actually, there was no problem getting topic name by using topic(1) function like this below;
$$aws/things/${topic(1)}/shadow/update
The problem was about policy permission. After adding necessary publish permissions to my policy. I start getting payloads.
For anyone else who can't figure out why
${topic(1)}
works for Arda, here is why:
https://docs.aws.amazon.com/iot/latest/developerguide/iot-substitution-templates.html
Turns out you can do "substitution templates" in the republish topic string.
Your next issue will be making sure the role assigned to the rule has a policy attached to it that allows it to publish to the iot core topic (doesn't get a policy that permits this automatically for some reason).
I'm transitioning towards more responsive front-end web apps and I have a question about model validation. Here's the set-up: the server has a standard REST API for inserting, updating, retrieving, etc. This could be written in Node or Java Spring, it doesn't matter. The front-end is written with something like Angular (or similar).
What I need is to figure out where to put the validation code. Here's the requirements:
All validation code should be written in one place only. Not both client and server. this implies that it should reside on the server, inside the REST API when persisting.
The front-end should be capable of understanding validation errors from the server and associating them to the particular field that caused the error. So if the field "username" is mandatory, the client can place an error next to that field saying "Username is mandatory".
It should be possible to validate correct variable types. So if we were expecting a number or a date and got a string instead, the error would be something like "'Yo' is not a correct date."
The error messages should be localized to the user's language.
Can anyone help me out? I need something simple and robust.
Thanks
When validating your input and it fails you can return a response in appropriate format (guessing you use JSON) to contain the error messages along with a proper HTTP error code.
Just working on a project with a Symfony backend, using FOSRestBundle to provide proper REST API. Using the form component of Symfony whenever there's a problem with the input a well structured JSON response is generated with error messages mapped to the fields or the top level if for example there's unexpected input.
After much research I found a solution using the Meteor.js platform. Since it's a pure javascript solution running on both the server and the client, you can define scripts once and have them run on both the client and the server.
From the official Meteor documentation:
Files outside the client, server and tests subdirectories are loaded on both the client and the server! That's the place for model definitions and other functions.
Wow. Defining models and validation scripts only once is pretty darn cool if you ask me. Also, there's no need to map between JSON and whatever server-side technology. Plus, no ORM mapping to get it in the DB. Nice!
Again, from the docs:
In Meteor, the client and server share the same database API. The same exact application code — like validators and computed properties — can often run in both places. But while code running on the server has direct access to the database, code running on the client does not. This distinction is the basis for Meteor's data security model.
Sounds good to me. Here's the last little gem:
Input validation: Meteor allows your methods and publish functions to take arguments of any JSON type. (In fact, Meteor's wire protocol supports EJSON, an extension of JSON which also supports other common types like dates and binary buffers.) JavaScript's dynamic typing means you don't need to declare precise types of every variable in your app, but it's usually helpful to ensure that the arguments that clients are passing to your methods and publish functions are of the type that you expect.
Anyway, sounds like I've found the a solution to the problem. If anyone else knows of a way to define validation once and have it run on both client and server please post an answer below, I'd love to hear it.
Thanks all.
To be strict, your last gate keeper of validation for any CRUD operations is of course on server-side. I do not know what is your concern that you should handle your validation on one end only(either server or client), but usually doing on both sides is better for both user experience and performance.
Say your username field is a mandatory field. This field can be easily handled in front-end side; before a user click submit and then been sent to the server and then get returned and shows the error code. You can save that round trip with a one liner code in front-end.
Of course, one may argue that from client-side the bad guys may manipulate the data and thus bypassing the front-end validation. That goes to my first point - your final gate keeper in validation should be on your server-side. That's why, data integrity is still the server's job. Make sure whatever that goes into your database is clean, dry and valid.
To answer you question, (biased opinion though) AngularJS is still a pretty awesome framework to let you do front-end validation, as well as providing a good way to do server-side error handling.