I'm trying to send a post request with parameters to Oracle APEX or PL/SQL procedure in the database. I'm currently exploring these avenues but to no avail. The PL/SQL method seems to involve using a DAD(Database Access Descriptor) to make a PL/SQL procedure web-enabled - however this sounds too complicated and not really ideal for the current environment where I am working in - need to edit the HTTP server and all that.
I'm not sure if Oracle APEX can accept a POST request and process that. Does anyone know of any solution of how either APEX could read a POST request or a PL/SQL procedure could be called using url and POST request parameters passed to it.
Sounds like you need to create a RESTful web service in APEX, assuming your client is able to make a HTTP request, which is kind of a given.
Have a look at this article. It should give you enough information to be able to create a REST API with the appropriate endpoint and POST handler.
http://www.modernapex.co.uk/building-a-todo-app-with-rest/
Related
This is a question to improve my understanding about OData and the process of OData services. I'm not sure about the process when an OData request is sent to the server from my Fiori app. The app is added to our Fiori Launchpad. When the user wants to create a new target group in the UI, a create request is sent. What happens then in detail? What I thought so far:
OData service checks the data
If the data is valid, a new entry in the database is created (HTTP POST)
If the data is not valid, the OData service sends an error
I'm not sure about what information is delivered by the OData service and what information is delivered directly from the database? Does the OData service work like a adjustor which transfers the messages sent from the database to the application?
I hope you can understand what I'm trying to figure out. Thank you for your time.
it depends how your backend-methods are implemented. Every Entityset usually has one of these Methods:
Get Entity
Get EntitySet
Create
Update
Delete
There are some more I guess, but these are mostly used by developers. You can redefine every single method and implement your own Business Logic in there.
So, let's assume you want to send data from the Frontend to your service and insert the data into a table inside your database. You have to redefine the create method of your entity and implement own logic. This could contain an insert into a database-table. You have to consider, that your oData Service will throw an Error if the types which are sent from the frontend do not match the Entity-Types (i.e. a String into an edm.Time type).
Here you can find all EDM.Types oData could consume and the correct mapping of the types:
https://help.sap.com/saphelp_gateway20sp12/helpdata/en/76/4a837928fa4751ab6e0a50a2a4a56b/frameset.htm
Hope this helps :)
I want to implement a query on my web page that gets results from another web service and displays them to the user. For this I ofcourse send the request as GET method from the web page. Server side, I process the request, get results from that web service and return them back to user.
However, I also want to save the results for future refernce. Something like history of queries. For this I will store the results in a database.
Now, the question is since I am upating my database everytime a query is made, should I be using POST method on the web page or GET would do? Does HTTP explicitly say anything for this scenario?
HTTP itself doesn't say you have to use POST -- the technology will work just fine if you're sending your data on queryparams.
But current convention says that you should use POST, specifically when using API services under a RESTful model. If you are passing data (even on the query params) that is creating a new record, it should use the POST verb. Updating it should use PUT.
It's going to get down to what your audience expects. If it's just an internal resource, go for it with GET. If you expect to open this up as a public service, use POST.
I have a program in which it insert a raw in a table after certain operations. I wan to call a web service in code behind to do some special tasks by the using of info that there is in the inserted row.
How I can do that?
Is it good idea to invoke this web service from a stored procedure or not? What are the other options?
More Details: Actually, I have an operation in my web application that take a long time to be completed and it is seriously time consuming operation. I don't want client wait until this process finish. That is why I decide write a web service to do this process in the background.
Therefore, I think it may be a good idea that when client request receive I insert his request in a table and call a web service to handle it. Moreover, I do not want to wait until web service return the result, so I will aware client from its result through the report. I do not know what is the best solution to handle it.
I usually keep myself far away from table triggers(it sounds like you're about to use an on insert trigger for a table).
I don't know your specific situation but you could either :
Call the webservice before or after you call the stored procedure, this way the data layer(stored proc) only handles data and nothing more. You're logical layer will handle the logic of calling an extra webservice.
Write a service that will periodicly read a table and notify the webservice of the latest modifications. More messy but it resembles more the effect you're trying to achieve.
There are probably more solutions but i'd need more information on what it exactly is you're doing. Right now it's kinda vague :)
It is never a good idea to call webservice from Stored procs or other DB objects. You can call it from your code, just after you execute the insert and commit it.
The problem it sounds like is that you cannot guarantee that the web service will be called unless you call it before committing the transaction. However, it sounds like the web service needs to be called after commit. In this case, it sounds like you should use a message queue. You could either build one in your database or you could use one off the shelf (http://aws.amazon.com/sqs/ or http://www.windowsazure.com/en-us/home/features/messaging/).
The steps would be:
Insert message into queue (after this is success you can return the call, depending on what your contract with the caller is)
Read message
Insert into table
Call web service
Delete message
The downside is that you will need to make the operations (inserting into the table and calling the web service) idempotent.
I'm trying to write a Postgres trigger such that when a configuration table is updated, a backend component is notified and can handle the change. I know that Oracle has the concept of a web/HTTP trigger, where you can execute an HTTP GET from the Oracle instance itself to a URL that can then handle the request at the application layer. I'm wondering if Postgres (v. 9.0.5) has the same feature, or comes with anything similar (and, subsequently, how to set it up/configure it)?
You could call a Python stored procedure with PL/Python from your trigger and make your http get request using Python's standard libraries.
Could someone please be kind enough to show me the best way to determine if a webservice (ASP.NET) exists at a given URL?
I assume an approach will be something along the lines of issuing a request using System.Net.Webclient but how could I determine if it is a valid webservice and what sort of request should I issue?
EDIT: To add a bit more context I am determining if a webservice exists because I am attempting to build a generic tool that uses arbitrary webservices.
The only way IMHO to be sure the service is up is to be able to call an innocuous method on the service and verify the response. Retrieving the WSDL is not sufficient.
There is a similar SO question on this here:-
How do I test connectivity to an unknown web service in C#?
I would ask for WSDL document. If you get it back it means that the service exists and you can check to WSDL for implemented methods.
Consider reading about WS-Discovery
http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.html