Basically looking for some advice on how to create a Sharepoint 2010 Timer Job that will go and consume a REST web service, receive the response as XML and per element returned create a new list item in a Sharepoint List.
Additional Information:
Just to test the connection I have created a REST data source which works fine and returns all the data into a test aspx page. I now want to be able to use the same connection to return the data in a Timer Job. I have got the Timer job set-up but just not clear how I go about calling the API from within it.
Thanks.
Querying a rest datasource from a timer job would work in exactly the same way as querying a rest datasource from any .NET app. The only gotcha is that you probably dont want to store the config in an app.config file.
Instead look at http://msdn.microsoft.com/en-us/library/ms734681.aspx which shows how to call WCF entirely from code.
Related
I want to create processer-group in Nifi.from somewhere I will get the tenant name Based on tenant I want to make processer-group, is it possible through programmatically? Please reply
As #daggett pointed out in the comments, the Apache NiFi REST API provides documentation on the expected input and response of every API method. To discover the correct method(s) to perform a task, it is often easiest to use the NiFi UI with your browser's developer tools open. The NiFi UI is a reference implementation of an API client, as all UI activities are performed using the API. Simply execute the desired task (i.e. drag a process group onto the canvas and enter a name) and watch the resulting requests fire in the developer tools window.
I'm looking into Volt as an option for building an Admin interface to our REST API. The API is a separate application. I would like the Admin application to persist data to the API but also store it's own data that is irrelevant to the API (such as admin users and notes on the API data objects) locally.
Is there a way to sync each local change in the Admin with our remote API, like a callback, for example? Or do I need to wait until the Data Provider API is ready as mentioned in the most recent Volt blog post (as of writing)?
So this is a fairly common thing, so I think long term the solution will be to support multiple stores in an app and have a REST data provider that you can extend. However that might be a while before that's ready. In the mean time, you can always load and save data via tasks. (I realize its not ideal, but it will work right now) Let me know if you need more info on using tasks to load and save. I'll add the REST data provider to the TODO list.
I have a Typical SOA web application which has the following components as expected.
The Web Client - Sprinv MVC
SOAP Services - Spring
The Reference Data is centralized which is exposed thru its own SOAP Services.
The SOAP webservice responses have codes for elements(like CountryCode, CityCode etc).
I need the suggestions as to what should be the best approach to for ex display the Country Description instead of the country code (which needs another SOAP call to reference data and same with other codes) on the web page ?
Few options are like:
Write a custom tag library which would do the necessary calls and get the data.
Fetch all the ReferenceData descriptions and put it into some kind of HashMap, add it to the model to be consumed by the web page.
Any other better ways please advice.
Since it's reference data, no one expect it to change very often, right? Retrieve them once and serve them up using #ModelAttribute. See here.
Spring MVC is still server side, so it can handle very large data e.g. all the street addresses in US. You simply need to make sure you add some sort of filter if you don't want to serve the entire collection. And simply partial update these reference data with the latest on regular basis.
Do I need to send individual entity updates to WebAPI, or can I POST an array of them and send them all at once? It seems like a dumb question, but I can't find anything that says one way or another.
Brad has a blog post that talks about implementing batching support in Web API.
Also, Web API samples project on codeplex has a sample for doing batching in web API hosted on asp.net.
It seems like WEB API 2 has support for this
From the site (Web API Request Batching):
Request batching is a useful way of minimizing the number of messages
that are passed between the client and the server. This reduces
network traffic and provides a smoother, less chatty user interface.
This feature will enable Web API users to batch multiple HTTP requests
and send them as a single HTTP request.
There are a number of samples for different scenarios on this page.
https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching
You will have to create an action that accepts a collection of items.
If all you have is an action that accepts a single item than you need to send separate requests.
With batching always think about how you would report the failures and whether a failing of a single item should invalidate the whole batch.
I'm having a really hard time trying to find a resource or online tutorial that explicitly walks you through setting up a WF4 workflow activity that can call out to an external web service. All the videos and online samples I've come across simply demonstrate how to consume a web service that's part of your Visual Studio solution, but my situation entails calling out to a web service on a non-Microsoft server.
I have a service reference added to my VS2010 workflow console project for the web service in question, and it's pointing to the WSDL of the external web service. So far, so good (I think). I have a very basic workflow sequence, using a SendAndReceiveReply workflow control to communicate with the external server, and I believe I have the Send piece configured correctly. The ReceiveReplyForSend is giving me trouble, however, and I'm not sure if I have its Content options set up the right way. I'm invoking an operation called FileCheck, which at the moment for testing purposes always returns a value of 1 like this:
<SOAP-ENV:Envelope>
<SOAP-ENV:Body>
<FileCheckResponse>
<FileCheckResult>1</FileCheckResult>
</FileCheckResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
If I try to run this, however, I get the error "Badly formed SOAP message." For what it's worth, my ReceiveReplyForSend has a single parameter set up called FileCheckResult, though I don't know if that's the correct way to get the above value.
I can put a breakpoint at either activity, but I have no idea how to see what the SOAP call looks like at that point. Can someone either give me some workflow Send/Reply debugging tips or point me in the direction of an excellent step-by-step tutorial of how to consume an external web service in WF4?
Update on Feb. 2, 2011: Thanks to Maurice's suggestion, I see exactly what is failing now. The web service call in my workflow is failing because Visual Studio is generating a reference to the wrong namespace in my workflow Send call. Here is the single bit of XML that is wrong in the SOAP message - I'll leave off the rest of the SOAP envelope for succinctness:
<FileCheck xmlns="http://tempuri.org/">
This is what the WCF Test Client generates, which gets a successful message in return:
<FileCheck xmlns="http://someserver.org/test/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
This is probably a really newbie question, but is there a setting somewhere that I'm overlooking that adjusts the xmlns value? I tried searching for "tempuri" in my project, but it's nowhere to be found, so I bet I'm overlooking a default setting somewhere.
Update on February 8, 2011: Maurice's latest tip did the trick! I needed to add the proper namespace to the ServiceContractName property for my Send workflow activity.
Adding a reference to an external web service is not much harder than one that is part of the same VS2010 solution. Only in this case you need to provide the URL where VS2010 can find the web service WSDL. As the communications mechanism is standard WSDL and SOAP there should not be a problem in calling the other service.
If you want to debug messages the best tool to use is Fiddler. It will let you see messages on the wire and even build request on the fly. If you have an existing client that can work with the service in question you can monitor its messages and compare them with the messages you are sending. Provided the service doesn't use complex and custom data types the WCF Test Client is a good way to check if the service responds with a standard .NET client app.
The SOAP namepsace is part of the ServiceContractName. Use the following syntax
{http://someserver.org/test/}FileService