You're viewing **Apigee Edge** documentation.  
[Go to the
**Apigee X** documentation](http://cloud.google.com/apigee/docs). info

On Wednesday, July 27, 2016, we released a new version of Apigee Edge for Public Cloud.

> [!NOTE]
> **Note:** **Private Cloud customers** : Is this cloud release included in your Private Cloud version? See your version's release notes to see which cloud releases it contains. Also, see [About release
> numbering](https://docs.apigee.com/release/apigee-edge-release-process) to understand how you can figure it out by comparing release numbers.
>
> **Questions or issues?** Contact [Apigee Edge Support](https://docs.apigee.com/api-platform/troubleshoot/support)
>
> **Release notifications** : See [Get Apigee Edge release notifications](https://docs.apigee.com/release/get-release-notifications).
>
> [Release notes home page](https://docs.apigee.com/release/notes/apigee-release-notes)

## New features and updates

Following are the new features and updates in this release.

### SOAP proxy behavior when
using the proxy wizard

When creating a SOAP-based proxy from a WSDL using the proxy wizard, there are two options for
proxy creation:

- **Pass-Through SOAP**, where the proxy simply passes through a SOAP request payload as is.
- **REST to SOAP to REST**, where the proxy converts an incoming payload such as JSON to a SOAP payload, then converts the SOAP response back to the format the caller expects.

This release includes the following updates to how these options behave. The differences
between the old and new behavior are in the policies and configurations that are automatically
generated by the proxy wizard.

> [!NOTE]
> **Note:** The new behavior applies only to new SOAP proxies you create with the proxy wizard. Existing proxies created with the previous behavior are unaffected.

#### Pass-Through SOAP

- All WSDL operations are now sent to the proxy base path "/" rather than to proxy resources
  (such as "/cityforecastbyzip"). Operation names are passed through to the target SOAP
  service. This behavior matches the SOAP specification.

  > [!NOTE]
  > **Note:** **Note about operation permissions in API
  > products** : With all operations using only the proxy base path "/", it becomes trickier to enforce access to APIs using API products, since there are no longer API resource names to specify in API products. For example, the previous behavior used API resources for different operations, such as /cityforecastbyzip for the GetCityForecastByZIP operation and /cityweatherbyzip for the GetCityWeatherByZIP operation. But with the new passthrough behavior, both operations are sent to "/". How then might you control access to operations in API products? One option is to create a custom attribute on a product, such as "allowedOperations", and populate it with the operations that the product allows. Then, when an API call includes an API key or OAuth token, a variable like the following becomes available, which contains the values of the `allowedOperations` attribute: `verifyapikey.Verify-API-Key-policy-name.apiproduct.allowedOperations`. Add a JavaScript policy that compares the operation to the allowed operations, then create a Raise Fault policy that returns an error if the comparison in the JavaScript is false.

- The generated proxy no longer supports JSON in the request. It supports only XML. The proxy ensures SOAP requests have an Envelope, Body, and a http://schemas.xmlsoap.org/soap/envelope/ namespace.

#### REST to SOAP to REST

- The proxy no longer support WSDL RPC (only Document/Literal is supported). This has not been tested with WSDL 2.0.
- The new behavior hasn't been tested with WS-Policy.
- The proxy lets you POST JSON data instead of FormParams.
- When you add CORS (Cross-origin resource sharing) support to the proxy using the proxy builder, you'll see the following enhancements:
  - **Access-Control-Allow-Headers** header: In addition to `Origin`, `x-requested-with`, and `Accept` headers, the Access-Control-Allow-Headers header also includes `Content-Type`, `Accept-Encoding`, `Accept-Language`, `Host`, `Pragma`, `Referrer`, `User-Agent`, and `Cache-Control`.
  - **Access-Control-Allow-Methods** header: In addition to `GET`, `PUT`, `POST`, `DELETE`, this header also includes the `PATCH` and `OPTIONS` verbs.
- When generating an API proxy for a WSDL, Edge reads any ComplexTypes that are defined as abstract in the WSDL and properly recognizes any instance types that are based on the abstract types.

#### wsdl2apigee open source command-line utility

Apigee also provides an open source command-line utility to generate passthrough or
rest-to-soap API proxies from WSDLs. See <https://github.com/apigee/wsdl2apigee>.

(EDGEUI-614)

## Bugs fixed

The following bugs are fixed in this release. This list is primarily for users checking to see
if their support tickets have been fixed. It's not designed to provide detailed information for
all users.

| Issue ID | Description |
|---|---|
| EDGEUI-621 | **Save as New API Proxy uses default name that includes scientific notation, such as "new-1.234568901234568e+53"** |
| EDGEUI-572 | **Ui displays "Error: Unknown Error" instead of "Error: Session timeout"** |