Thank you for checking my question,
I'm developing a Boomi custom connector which consumes Restful API.
I have implemented the GET operation which receives only 1 ID parameters from User and QUERY operation which requests multiple parameters based on response profile and filtered expressions.
However, for API get request with multiple path parameters are required, both GET and QUERY operations seems not suitable.
For example: users//productTypes/
The above endpoint needs 2 parameters "userID" and "productTypeID"
I have implemented the EXECUTE operation and import an input profile with 2 parameters. The connector worked but it's not fully what I expect.
EXECUTE operation no parameters
EXECUTE operation
My expectation is to develop an operation with the same behaviour with GET operation.
After importing response profile, Connector prompts the user with a warning sign about missing parameters
Adding parameters in the parameter tab should be the only way to make the operation work
The connector will not require any input profile from the payload.
The purpose of these requirements is to improve user experience and avoid confusion on how to add the parameters.
GET operation
So my questions are:
Which type of operation should I use for the above requirements/expectation?
How to require multiple parameters with the warning sign, and if possible not to consume the payload/request profile
If you can attach related resource to implement those features, that would be great.
Thank you
Bryan
Related
I'm using Node.js and ws for my WebSocket servers and want to know the best practice methods of tracking connections and incoming and outgoing messages with Azure Azure Application Insights.
It appears as though this service is really only designed for HTTP requests and responses so would I be fine if I tracked everything as an event? I'm currently passing the JSON.parse'd connection message values.
What to do here really depends on the semantics of your websocket operations. You will have to track these manually since the Application Insights SDK can't infer the semantics to map to Request/Dependency/Event/Trace the same way it can for HTTP. The method names in the API do indeed make this unclear for non-HTTP, but it becomes clearer if you map the methods to the telemetry schema generated and what those item types actually represent.
If you would consider a receiving a socket message to be semantically beginning an "operation" that would trigger dependencies in your code, you should use trackRequest to record this information. This will populate the information in the most useful way for you to take advantage of the UI in the Azure Portal (eg. response time analysis in the Performance blade or failure rate analysis in the Failures blade). Because this request isn't HTTP, you'll have to mend your data to fit the schema a bit. An example:
client.trackRequest({name:"WS Event (low cardinality name)", url:"WS Event (high cardinality name)", duration:309, resultCode:200, success:true});
In this example, use the name field to describe that items that share this name are related and should be grouped in the UI. Use the url field as information that more completely describes the operation (like GET parameters would in HTTP). For example, name might be "SendInstantMessage" and url might be "SendInstantMessage/user:Bob".
In the same way, if you consider sending a socket message to be request for information from your app, and has meaningful impact how your "operation" acts, you should use trackDependency to record this information. Much like above, doing this will populate the data in most useful way to take advantage of the Portal UI (Application Map in this case would then be able to show you % of failed Websocket calls)
If you find you're using websockets in a way that doesn't really fit into these, tracking as an event as you are now would be the correct use of the API.
I want to test a REST service that returns the detail of a given entity identified by an UUID, i.e. my consumer pact has an interaction requesting a GET like this:
/cities/123e4567-e89b-12d3-a456-426655440000
So I need this specific record to exist in the Database for the pact verifier to find it. In other projects I've achieved this executing an SQL INSERT in the state setup, but in this case I'd prefer to use the microservice's JPA utilities for accessing to the DB, because the data model is quite complex and using these utilities would save me much effort and make the test much more maintainable.
The problem is that these utilities do not allow specifying the identifier when you create a new record (they assign an automatic ID). So after creating the entity (in the state setup) I'd like to tell the pact verifier to use the generated ID rather than the one specified by the consumer pact.
As far as I know, Pact matching techniques are not useful here because I need the microservice to receive this specific ID. Is there any way for the verifier to be aware of the correct ID to use in the call to the service?
You have two options here:
Option 1 - Find a way to use the UUID from the pact file
This option (in my option) would be the better one, because you are using well known values for you verification. With JPA, I think you may be able to disable the auto-generation of the ID. And if you are using Hibernate as the JPA provider, it may not generate an ID if you have provided it one (i.e. setting the ID on the entity to the one from the pact file before saving it). This is what I have done recently.
Using a generator (as mentioned by Beth) would be a good mechanism for this problem, but there is no current way to provide a generator to use a specific value. They generate random ones on the fly.
Option 2 - Replace the ID in the URL
Depending on how you run the verification, you could use a request filter to change the UUID in the URL to the one which was created during the provider state callback. However, I feel this is a potentially bad thing to do, because you could change the request in a way that weakens the contract. You will not be verifying that your provider adheres to what the consumer specified.
If you choose this option, be careful to only change the UUID portion of the URL and nothing else.
For information on request filters, have a look at Gradle - Modifying the requests before they are sent and JUnit - Modifying the requests before they are sent in the Pact-JVM readmes.
Unfortunately not. The provider side verifier takes this information from the pact file itself and so can't know how to send anything else.
The best option is to use provider states to manage the injection of the specific record prior this test case (or to just have the correct record in there in the first place).
You use the JPA libraries during the provider state setup to modify the UUID in record to what you're expecting.
If you are using pact-jvm on both the consumer and provider sides, I believe you may be able to use 'generators', but you'll need to look up the documentation on that as I haven't used them.
I am working on a Web API service for our Web application (current project). One controller in the Web API will be responsible to retrieve a list of entities of a certain type. So far so good. The problem is that we have a request to filter the list based on search criteria. This search/filter criteria has about a dozen different parameters, some of which can be null. So I figured I create a custom class (let's call it "EntityFilterCriteria") and I instantiate it on the Web application side with whatever filtering fields the user enters (I leave the ones that the user do not enter set to null). Now how do I pass this object to my Web API method? I do not want to build an URL with all parameters because it's going to be a huge URL, plus some parameters may be missing. I can't have a body in the GET HTTP command to serialize my EntityFilterCriteria object so what do I use? POST? It is not really a POST because nothing is updated on the server side. It is really a GET, as in "get me all the records that match this search criteria". What is the common approach in such situations?
Thanks,
Eddie
Serialize the class to JSON and post it to your server, the JSON string will be your post body. Once it is posted you can then deserialize into a class with the same signature. Most languages have either built-in support or free 3rd party modules that can do this for you.
Well the initial danger of using GET for such a request is that the longest url you can send which is guarenteed to work across all web browsers and servers is about 1400 bytes in length.
Personally I would use JSON to encode all of your filter parameters and submit them to the server in the body of a POST command due to the lack of size limit on the sent data.
While there is a semantic difference between GET and POST commands which was intentioned when the HTTP RFC's were written decades ago, those decades of practical use have shifted rather significantly (in the same way that barely anybody uses PUT or DELETE)
I don't see any drawbacks to use a POST method to execute your query and get the result back. For example, ElasticSearch uses this approach to execute queries against the database. See this link for example: http://exploringelasticsearch.com/searching_data.html. In REST, POST isn't necessary used to update data.
Hope it helps.
Thierry
I have a need to create a BizTalk 2010 application to poll information and I have found this useful blog Polling Oracle Database Using Stored Procedures, Functions, or Packaged Procedures and Functions.
My questions are 2 folds:
The blog hard coded the parameter for the procedure in the package in the polledDataAvailable and the PolledStatement. How do I pass the actual parameters that is going to change? For example, I want to have the ability poll all orders from a customer, and not just the customer hard-coded 'ABC'. The ID of the customer will be defined at real time.
Without using extra receive ports but just based BizTalk monitor (referring back to the blog), how do I examine the results (i.e. viewing the records being polled) on BizTalk monitor?
Maybe the parameter value seems to be hard coded to call the function in the query statement SELECT CCM_ADT_PKG.CCM_COUNT('A02') FROM DUAL , but the real parameters values are passed to the generated instance from the input schema in the section "Modify XML content setting up the right parameters."
I don't know how your message result will be used, but if you use a send port to send the result somewhere, but you can create a simple FILE send port to store your message instance.
I'm generally following the recommendations when it comes to choosing between HTTP GET and HTTP POST as allowed method for action on controller in ASP.NET MVC.
When there is no change on server side, aka I want to retrieve a resource, HTTP GET is allowed.
When user is about to submit some data that will be persisted, HTTP POST is required.
Now here comes the issue with the gray zone:
What if user wants to download a file?
Usually I would set this as HTTP GET (file is stored in database due to security reasons) as there is no change done on the server.
What if I want to log that file X was downloaded by user Y?
There is now server-side change as new log is created. Is that a good enough reason to change HTTP method from GET to POST?
I've found exact explanation on how to deal with this:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Definition of safe methods:
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow
the user to be aware of any actions they might take which may have an
unexpected significance to themselves or others.
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, so
therefore cannot be held accountable for them.
Important part is emphasized below, which gives resolution to my problem:
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, so
therefore cannot be held accountable for them.
So since user did not request the logging to be performed, it is considered to be side-effect and therefore I can continue setting GET as HTTP method for file download.