Webservices

Force.com provides five types of Web service APIs: Enterprise, Partner, Metadata, Apex, and Delegated Authentication. Each has its own WSDL describing the methods and data structures available. The WSDL can be used to generate stub code in strongly typed languages, allowing the Web services to be incorporated in programs without manual construction and parsing of complex SOAP messages. When accessing data in Force.com using Web services, the choice is between Enterprise and Partner APIs. Both APIs have the same core set of calls, such as query to exe-cute a SOQL query. The difference between the APIs is how database objects are represented in your code.

The Enterprise API provides a strongly typed representation of the objects in yourForce.com database. This allows your code to operate naturally with Force.com data, using the field names and data types as you would in Apex code. When you redefine an object or add a new object, the Enterprise WSDL is automatically updated to reflect the changes. You need to manually regenerate the client code from the latest WSDL, but this is a small price to pay for concise, maintainable code.

The Partner API is designed for independent software vendors who write applications that must interoperate with many different Force.com organizations. They cannot rely on a single, static representation of standard and custom objects, because all customers of Force.com are free to create their own database schemas. With the Partner API, you can write generic code to access any object in any Force.com organization. It’s more verbose to work with than the Enterprise API, but more flexible as well. There are also three APIs that do not work with Force.com data. The Metadata API allows manipulation of objects, fields and other elements of your Force.com configuration. It provides access to low-level development-related features such as the generation of Apex from WSDL, test execution and anonymous Apex execution. The Delegated Authentication API enables a program running outside of Force.com to be invoked whenever a user attempts to log in to Salesforce, allowing it to decide whether the user is valid.

Service Definition

Global Class Access Modifier: A class that contains any Web services must use the global access modifier. This means the class is visible to all programs running in the Force.com organizations

Web Service Methods: Each method accessible via Web service call must be defined with the web service keyword. These methods must also be static.

Security: Web service methods run as a system administrator, without regard for object, field, or record-level sharing rules. To enforce normal security and sharing rules, define the class with the with sharing keyword,  nSupporting Classes: User-defined Apex classes, inner or outer, that are arguments or return values for a Web service method must be defined as global. Member variables of these classes must be defined using the webservice keyword.

No Overloading: Web service methods cannot be overloaded. Overloaded methods result in a compile error. nProhibited Types: The Map, Set, Pattern, Matcher, Exception, and Enum types are  not allowed in the arguments or return types of Apex Web services. Additionally, Web services written in Apex must abide by its governor limits.

Calling a Custom Web Service

To call a custom Web service from client code, follow these steps:
1. In the App Setup area, click Develop➝ Apex Classes. 
2. Locate the class containing the Web service and click the WSDL link.
3. Save the WSDL on your local file system. You’ll need this plus the Enterprise WSDL in order to call the custom Web service. 
4. Generate stub code from the custom WSDL and add it to your project.
5. Use the login method of the Enterprise WSDL to get a session identifier. Provide the session identifier when calling the custom Web service.

The steps needed to generate Apex from WSDL:

1. Save the WSDL file on your local machine.
2. Go to the App Setup area and click Develop➝ Apex Classes.
3. Click the Generate from WSDL button
4.Click the Browse button and locate the WSDL in your file system and then click the Parse WSDL button. The WSDL must describe a document-style service because RPC is not supported.
5. Each WSDL namespace can be mapped to an Apex class name to be generated. You can map multiple namespaces to the same class.Force.com suggests an Apex class name based on the WSDL, but you can override this suggestion. When you’re done naming the classes, click the Generate Apex code button.
6. If you refresh your Force.com IDE by right-clicking the project and selecting Force.com➝ Refresh from Server, you should see the new Apex class. If not, make sure that it was generated successfully and that you’ve subscribed to new Apex classes by right-clicking the Force.com project and selecting Force.com➝Add/Remove Metadata Components.

Before you can run this code, you must authorise Force.com to make an outbound call to the endpoint of the Web service. Go to the Administration Setup area and click Security Controls➝ Remote Site Settings and add the host.

Using Analytic Snapshots.  Analytic snapshots move data resulting from running a report into a custom object. Ordinarily reports are run interactively by users in the native user interface, scheduled for execution with results emailed to users, or exposed as dashboard components.Force.com does not maintain the report output anywhere within the platform. But when report data is captured in analytic snapshots, it becomes broadly available to the platform, accessible any- where custom objects are used, without executing the report again.