Wednesday Jun 08, 2016

New tools for Oracle Database as a Service and Oracle MAF in OEPE 12.2.1.3

Oracle Enterprise Pack for Eclipse (OEPE) 12.2.1.3 provides new feature support for Oracle Mobile Application Framework (MAF) 2.3.0.1 and new support for Oracle Cloud.

Support for Oracle Mobile Application Framework 2.3.0.1


Oracle MAF 2.3 is a major feature release which introduces the following new capabilities

  • Window Platform Support - In addition to iOS and Android deployment targets, you can now deploy MAF applications to the Universal Windows Platform (UWP). MAF 2.3 apps can run on Window devices based on the x86 chipset. MAF 2.3 supports UWP native look and feel and can conform to UWP design patterns
  • Enterprise Mobile Management (EMM) Support - MAF 2.3 adds integration with EMM solutions from Airwatch and Mobile.
  • New animation effects for ListView components and new Data Visualization enhancements for Charts, Graphs, and Gauges.
  • MAF 2.3.0.1 runtime is shipped out of the box with OEPE 12.2.1.3 while still maintaining backwards compatibility with past MAF releases.

More details on the new MAF 2.3 feature set can be found on the MAF Blog and MAF 2.3 release notes

Support for Oracle Database as a Service


OEPE 12.2.1.3 adds support for the Oracle Database as a Service and integrates existing OEPE Oracle Database tooling with the Oracle Cloud.
  • Connect to Oracle Database as a Service accounts through Oracle Cloud View either through https or SSH

  • Work with Database objects and perform basic administrative tasks against Database instances from with Eclipse

  • Use the Schema Designer to work with ER diagrams in the Cloud

  • Design, test, and execute SQL/PL-SQL queries against Database as a Service instances
  • Generate JPA entities from Database as a Service instances for use in JavaEE and Oracle ADF applications.

For more information including download links, please visit the Oracle Enterprise Pack for Eclipse OTN page.

Wednesday Dec 09, 2015

OEPE 12.2.1.1 brings updated tools for Java Cloud Service and Oracle MAF

Oracle Enterprise Pack for Eclipse (OEPE) 12.2.1.1 released last week with new tooling support for Oracle MAF and improved tools for Oracle Java Cloud Service.

Support for Oracle Mobile Application Framework 2.2


OEPE 12.2.1.1 now ships with runtime and design time tools for Oracle MAF 2.2. New Design time tools for MAF 2.2 include the following
  • Allow Native Device Access - A new option to Allow/Disallow native device access is available both application-wide and at the feature level. Configuration for native device access can be configured globally in the Mobile Application Editor and in the Mobile Feature Editor.
For more information on MAF 2.2 Runtime features, please see the MAF 2.2 Runtime Release Notes.

In addition OEPE 12.2.1.1 continues to support older releases of MAF. Check the OEPE Eclipse Update Site to download older MAF runtime and design-time tooling bundles.


Updated Oracle Java Cloud Service Tools


Oracle Java Cloud Service configuration has been streamlined in OEPE 12.2.1.1. When browsing available services in the Oracle Cloud View, you can now more easily setup a connection to the Java Cloud Service.

Oracle Cloud View

Multiple communications protocols are available including new wizards to facilitate SSH tunneling to Java Cloud Service. 

SSH JCS Setup

 Check out the OEPE OTN page for more information and downloads

Wednesday Oct 28, 2015

Getting Started with MAF and Mobile Cloud

Marcelo Jabali shows how easy it is for MAF applications to pull data from Mobile Cloud Service.

Check it out.


Friday Oct 23, 2015

Oracle Enterprise Pack for Eclipse 12.2.1 now available on OTN

Oracle Enterprise Pack for Eclipse (OEPE) 12.2.1 is now available on the Oracle Technology Network (OTN) and provides new support for Oracle Fusion Middleware 12.2.1 technologies. This includes design time tools for Oracle WebLogic Server 12.2.1, Oracle Coherence 12.2.1, and Oracle ADF 12.2.1

Updated Tools for Fusion Middleware 12.2.1


OEPE provides rich design-time tools for the Fusion Middleware 12.2.1 Suite of products while maintaining backward compatibility with previous releases. Updated tools include:
  • Manage, deploy, and debug applications to local and remote WebLogic Server 12.2.1
  • Support for WebLogic Server shared libraries
  • Rich editors for WebLogic Server deployment descriptors
  • Integrated tools for WebLogic Scripting Tools
  • Support for JavaEE 7 development on WebLogic Server 12.2.1
  • Support for WebLogic Server deployment plans
  • Updated tools to create and develop distributed caches based on Coherence 12.2.1
  • New editors for Coherence 12.2.1 descriptors
  • Packaging and deployment tools for Coherence GARs
  • Updated design-time tools for Oracle ADF 12.2.1 including ADF Faces, ADF Tasks Fows, Data Controls, Bindings, and Lifecycle Debugging
  • AppXRay enablement for Oracle ADF 12.2.1
Checkout the OEPE Downloads page to get the latest installer and start developing Fusion Middleware 12.2.1 applications.



Thursday Oct 22, 2015

Connecting MAF Applications to Mobile Cloud Service

Just in time for Oracle Open World 2015, a new tutorial is now available that teaches you how to use Oracle MAF to consume and test mobile backend services from Mobile Cloud Service.

 Before getting started with this tutorial, you will need to complete the Mobile Cloud Service: Putting It All Together tutorial at least through Associating APIs with the Mobile Backend section. This will setup your first mobile backend based on the FIF_incidents.raml sample API.  From there you can consume that FiF_incidents with the MAF application that you develop in Eclipse.

Consuming Mobile Cloud Service APIs using Eclipse 

In the first part of the tutorial, you will use the Oracle Cloud view to connect to and browse your API catalog in Mobile Cloud Service. This is an easy way for the mobile app developer to see which mobile endpoints are available for consumption.

Next, you will introspect into the RAML definition, test using the REST Test Client, and create client APIs for the mobile application.

Finally, you will develop an Incident Tracker app using Oracle MAF in Eclipse. Data Controls will simplify the bindings between the UI components and REST client APIs. 

For more information on Oracle Enterprise Pack for Eclipse, checkout the OEPE OTN page for additional tutorials, downloads, and discussions. 

Wednesday Oct 21, 2015

Oracle Open World 2015 - Eclipse and Mobile Sessions Content

Conference season is upon us and OEPE is participating in a number of Mobility related presentations at Oracle Open World and JavaOne 2015 next week. Between numerous sessions, hands on labs, and demos we will cover topics ranging from mobile app development, mobile development life cycle challenges, mobile backend development and more.  

Here are some of the Mobile sessions that we recommend you attend if you are an Eclipse fan.


Building iOS Apps with Java 8 [CON1588]
Monday, Oct 26, 12:30 p.m. | Hilton—Continental Ballroom 4

Developing On-Device Mobile Apps with Oracle Mobile Application Framework [HOL10379]
Tuesday, Oct 27, 8:45 a.m. | Hotel Nikko—Nikko Ballroom III (3rd Floor)

Developing Mobile Applications with Mobile Cloud Service
Oct 27 10:30AM | Moscone South Demogrounds – Mobile Showcase Theater

Mobilize Oracle Enterprise Applications using Oracle Mobile Cloud Service [HOL10367]
Wednesday, Oct 28, 8:45 a.m. | Hotel Nikko—Mendocino I/II (2nd Floor)

Developing On-Device Mobile Apps with Oracle Mobile Application Framework [HOL10379]
Wednesday, Oct 28, 2:45 p.m. | Hotel Nikko—Nikko Ballroom III (3rd Floor)

Building iOS Apps with Java 8 [CON1588]
Thursday, Oct 29, 9:00 a.m. | Hilton—Continental Ballroom 1/2/3

DevOps for Mobile in the Cloud [CON8660]
Thursday, Oct 29, 12:00 p.m. | Moscone South—304

Integrating Calls in Oracle Mobile Cloud Service in Oracle Mobile Application Framework [CON8318]
Thursday, Oct 29, 2:30 p.m. | Moscone South—270

Also remember to swing by the Mobile Showcase in Moscone South Demogrounds and the JavaOne Mobile Demo booth to ask questions and see demos on Eclipse and mobile development.

 For more details on session information, check out the Focus On: Oracle Mobile site. 

See you next week! 

Tuesday Sep 01, 2015

New Tools for Mobile Developers in OEPE 12.1.3.8

Oracle Enterprise Pack for Eclipse 12.1.3.8 is now available on OTN Downloads for both Eclipse Luna and Mars. Whether you are developing mobile backend APIs or the mobile client applications themselves, OEPE provides the tools for the full mobile development life cycle.

New Tools for Mobile Cloud Service

Oracle Mobile Cloud Service (MCS) provides robust tool suite to design, manage, monitor, and secure the back end services required for an enterprise mobile strategy. OEPE 12.1.3.8 users can connect to Mobile Cloud Service through the Oracle Cloud view to develop their mobile backends and use them to create mobile applications. MCS tools within OEPE include:

  • Connect to MCS through Oracle Cloud View
  • Browse and analyze API assets including; Mobile Backend Definitions, Mobile APIs, and Connectors
  • Download and analyze RAML API definitions
  • Model and Test mobile service endpoints in the REST Service Editor
  • Create REST Clients from Mobile Backends for use in mobile client applications
  • Build Oracle MAF applications which consume APIs from Mobile Cloud Service

Oracle Mobile Application Framework 2.1.3 Update


OEPE MAF design-time and runtime tools have been updated to support Oracle MAF 2.1.3. All existing mobile development tools have been updated to support the new Oracle MAF release while still continuing to support past Oracle MAF versions.

Monday Jun 22, 2015

New Support for Oracle Mobile Cloud Service in OEPE

Oracle Mobile Cloud Service provides robust tool suite to design, manage, monitor, and secure the back end services required for an enterprise mobile strategy. Mobile developers can now use Oracle Enterprise Pack for Eclipse to connect to and manage their Mobile Cloud Service assets. Once you have activated your Mobile Cloud Service account, service details will show up immediately in the OEPE Oracle Cloud view.

 Use the Oracle Cloud view to browse and manage your Mobile APIs, Mobile Backends, and Connectors to external resources.


OEPE makes it easy to develop MAF applications which consume back end services defined in Mobile Cloud Service. Simply browse your API catalogs, select the back end services, and generate the REST Client code for use in the the mobile application. Use REST Service Editor to model and test the mobile APIs in Mobile Cloud Service.

To get started with OEPE, Mobile Cloud Service, and MAF check out the video below:


Tuesday Apr 21, 2015

Working with variables in the REST Service Editor

Working with Variables in the REST Service Editor

 By Preston Appel

This blog continues surveying the REST Service Editor's ability to explore an existing REST API and to describe that API. Here we look at how variables are used in the address of a request on the REST Client page. We'll also see how this is modeled on the REST API page. Finally, we’ll see how variables are translated to code with the artifact generation capability of the editor.

This blog continues work that is described in the blogs Introduction to the REST Service Editor, Part 1 and Introduction to the REST Service Editor: Generation, Part 2. We recommend reviewing these blogs before proceeding if you’re not familiar with the REST Service Editor.

Our Description of the REST API and Data Types

This blog builds on our description of the REST API and Data Types that we've compiled through the course of several blogs. To get up to speed, here is the REST API we’ve described so far, which is expressed as a tree of paths with their associated requests. The root path is "http://localhost:4545." We'll alter its child path "departments" by adding a child path and a request.
REST API model from previous work

We'll also be using the Department data type that we previously imported.
Data Types from previous work

With that background, let's introduce a variable.

Exploring a REST API Using Variables

On the REST Client page, this version of the REST Service Editor supports variables for the address URI. These variables take the form of {variable-name}. In the exposed REST API that we're exploring, we can request a single department with a URI like "http://localhost:4545/departments/dep2." In this case "dep2" indicates that we'll return the department with an id of 2. Here we'll use a variable for the id: "http://localhost:4545/departments/dep{id}." There's nothing special about the variable name we've used. We could just as easily have written "dep{identifier}." In other words, it doesn't have to match the name of the attribute of the department payload.
Address URI with variable

Now, the curly brace characters are not legal in a URI. On the REST Client page, when we send the request, the variable (including its curly braces) will be replaced by an actual value. However, while typing the variable, you will see that the curly braces cause a validation error—but only when you have only one of the curly braces. The validation recognizes when we have valid variable syntax.
Validation of illegal characters in the Address URI

We'll restore the address to "http://localhost:4545/departments/dep{id}" and click the Send Request button to see how the variable substitution occurs.
Send the request with a variable

We enter the value for the id variable in the Replace Variables dialog. If we had other variables in the address, they would also appear in this dialog.
Replace Variables dialog

Here we can see that the response contains the department with id 2.
Response returning department 2

Now let's import the REST Client information to get the path with this variable into our description.

Importing a Variable

Click on the Import the REST Client Information button to start the process.
Import the REST Client Information button

This brings up the Import REST Client Information dialog. We don't really need to import the data types because we have them from previous work we did on the description. However, to illustrate that we are working with the same data types, we'll leave this checked.
Import REST Client Information dialog

On clicking the Next button, we enter the name of our request "getDepartment." We also see that we've already imported the "http://localhost:4545" and "departments" segments as paths in our tree, so we just need to import the final segment "dep{id}."
Import Request page of dialog

Clicking the Next button again, we confirm that we already have the data types we need. We'll leave "Merge types into the existing matching domain types" checked to use our existing data types. See the Introduction to the REST Service Editor, Part 1 blog for details on how we imported the Department and Employee data types.

A few words are in order about the names of the data types. The Dep data type name comes from the last segment in the address, dep{id} with {id} dropped. The Employees1 data type name comes from the name of the employees array in the response; it is disambiguated from the existing Employees data type by adding 1 to the end. This is also covered in the Introduction to the REST Service Editor, Part 1 blog.

After we click the Finish button, we are taken to the REST API page that shows our new "getDepartment" request. It has been added under the new "dep{id}" path that was added to our tree of paths.
REST API model with new path and request

At this point we'll generate artifacts for our REST API description.

Note: Currently, the REST Service Editor does not support setting the type of the variable in the path segment. So, for example, we can't specify that the {id} in the dep{id} path is an Integer. There is more on this in the generation section below.

Artifact Generation and Variables

After saving, we click the Artifact Generation button to generate Java 8 code for our request.
Artifact Generation button

We won't go through the screens of the Artifact Generation wizard here. Instead, please refer to the Introduction to the REST Service Editor: Generation, Part 2 blog for the details. The code below shows the call on the RESTService class to get the department. Note that an id must be passed to the method.

Note: Since in the REST API model we do not yet support specifying the type of the variable in a path segment, the id parameter in the getDepartment method is generated as an Object. This becomes an issue if this code is to be used in a data control to bind to the UI. If that is the case, subclass the RESTService class (so that future regenerations of code will not replace your change) and overload the getDepartment method to take an Integer type for the id parameter.

package mobile.model.service.localConnection;

import mobile.model.datatype.DepartmentObject;

import mobile.model.restapi.LocalClientContextFactory;
import mobile.model.restapi.PathFactory;

import oracle.eclipse.tools.rest.runtime.client.ClientContext;

/**
 * Service class generated to expose requests defined on the REST Service file:
 * /ViewContent/restServiceEditorDemo.xmi (last modified: 2015-03-11 12:27:11.643)
 */
public class RESTService {
  public DepartmentObject getDepartment(Object id) throws Exception {
    try (ClientContext context = LocalClientContextFactory.INSTANCE.create(ServiceUtil.CONNECTION_NAME)) {
      return PathFactory.INSTANCE.createLocalConnectionPath(context).path(context.getConnectionPath())
        .getDepartmentsPath()
        .getDepidPath(id)
        .invoke()
        .getDepartment();
    }
  }
}

To conclude, here's the class generated for the new path: mobile.model.restapi.localConnection.departments.DepidPath. (For the sake of space, the package and imports are not shown.)

/**
 * Interface generated for the 'dep{id}' path defined on the REST Service file:
 * /ViewContent/restServiceEditorDemo.xmi (last modified: 2015-03-11 12:27:11.643)
 */
@PathValue(value="dep{id}", parameters="id")
public interface DepidPath extends PathObject {
  @RequestAccessor
  public static interface Request {
    @Action(HTTPMethod.GET)
    @Header(name="Accept", value="application/json")
    @Output(representations=@Representation(type=DepartmentObject.class))
    DepartmentObject getDepartment() throws RequestException;
  }
  
  @Override
  DepartmentsPath parent();

  /**
   * @return creates a new object that exposes the requests
   *         defined for this path
   */
  Request invoke();
}

Tuesday Apr 14, 2015

Working with secure REST Services: Basic Authentication

Working with secure REST Services: Basic Authentication

By Preston Appel

The REST Service Editor's REST Client page allows users to experiment with existing REST APIs. The blog Introduction to the REST Service Editor, Part 1 provides an example of sending a simple GET request to a server and storing a description of the request and of the received payload. That example did not require any authentication. This blog expands on that case by describing how to set up HTTP authentication to explore REST APIs that require this type of authentication. A later blog will cover OAuth 2 authentication.

Let's look at this case of a resource that requires authentication. If we enter the address of this resource and click the Send Request button, we receive back a response with status 401 Unauthorized. Note that throughout this blog, I've obscured the address URI since it is not publically available.
REST Service Editor's REST Client page showing Unauthorized response

At this point, the user will need to look up what authentication is required for the REST API they are accessing. Once this information is known, authentication is set up by clicking the Set Authentication Information button. The blue circle on the button indicates that no authentication information has been entered yet.
REST Client page's Set Authentication Information button

Clicking the button pops up the Authentication Information wizard and we select HTTP (basic, digest, universal) for our type of authentication.
Authentication Information dialog's authentication type page

Clicking the Next button, we can now enter the username and password.
Authentication Information dialog's HTTP page for username and password

Now, when we look at the Set Authentication Information button, we don't see the blue circle, indicating that we have entered the authentication information. The tooltip shows the type of authentication that was set.
Set Authentication Information button showing authentication entered

One point of clarification: the fact that the blue circle has disappeared from the Set Authentication Information button does not indicate that the authentication information is valid, only that the required fields for the particular authentication type have been entered.

The REST Service Editor fully supports undo and redo, so it is easy to reverse what we've just done. We can also click the Set Authentication Information button again and select None for the authentication type (and then click the Finish button).

Now when we click the Send Request button, we see that our request was properly validated and we now have a valid response.
REST Client page showing successfully authorized response

Remember that the REST Client page is not part of the persistent state of the REST Service Editor, so the authentication information is not saved. This authentication mechanism is provided so that a user can explore a REST API that requires authentication (and then optionally store a description of the request and of the received payload.)

Friday Apr 10, 2015

OEPE 12.1.3.5 brings new tools for Storage Cloud Service and MAF 2.1.1

Oracle Enterprise Pack for Eclipse (OEPE) 12.1.3.5 is now available from the Oracle Technology Network and includes new tools for Oracle Cloud services and Oracle MAF.

New Tools for Oracle Storage Cloud Service


Oracle Storage Cloud Service is a secure, elastic, and on-demand cloud based storage solution. Customers with Storage Cloud Service accounts will be able to interact with their service instances from within OEPE 12.1.3.5 through the Oracle Cloud view. The Storage Cloud Service design time tools support a number of actions including:
  • Create new storage containers.
  • Store and retrieve objects in the storage containers.
  • Rename the storage object and manifest object.
  • Update the container and object metadata.
  • Support transparent encryption and define access controls to containers.
  • View the properties of any container and object.

Support for Oracle Mobile Application Framework 2.1.1


OEPE MAF design-time and runtime tools have been updated to support Oracle MAF 2.1.1. All existing mobile development tools have been updated to support the new Oracle MAF release while still continuing to support past Oracle MAF versions.

New MAF 2.1.1 runtime features include:

Local Notification support - MAF 2.1.1 provides support for scheduling, cancelling and receiving local notifications via the Device Feature Data Control, as well as Java and JavaScript APIs.

Support for completely disabling logging -  MAF 2.1.1 provides support for completely disabling all logging from a MAF app. To force this behavior, add the following to the app's adf-config.xml.

Wednesday Mar 18, 2015

REST Service Editor Query Parameters

REST Service Editor Query Parameters

By Preston Appel

This blog covers how to specify query parameters using the REST Service Editor. As you will see, it is possible to set the scope of the query parameters to every request of a given URI or to just a single request. We will also review how to modify the output representation to only contain certain attributes. (This is also covered in the Modeling a POST Request and Redirection in the REST Service Editor blog.)

Background of Our REST API Model

In previous blogs (Introduction to the REST Service Editor, Part 1 and Modeling a POST Request and Redirection in the REST Service Editor), we described a REST API that had been exposed by an application. This is shown below on the REST API page of the REST Service Editor.
REST Service Editor's REST API page showing model

Based on the documentation of the existing REST API that we are describing, we know that we can pass the query "verbose=false" to our GET request for departments. In this case, the response's JSON payload will just contain a summary description of each department. Usually, when we send a GET request to "http://localhost:4545/deparments," it returns multiple departments, where each department has an id, name, optional manager and an array of employees. When the query "verbose=false" is added to that URI, the JSON payload in the response will just contain the id and name of the department. How might we model this?

Modeling a Query on the Path

Let's say that we want to model this by adding the query to the "departments" path. (In this case, we don't actually want to do this, but we’ll get to that in a moment.) First, remember that the "departments" path is a child of the root path "http://localhost:4545." Since the paths will be combined into the address "http://localhost:4545/departments," we are just altering the address to include a query. We could just type the query at the end of the "departments" path, but to ensure we have the correct syntax (and to encode any illegal characters), we will use the Compose Address button to do this work.
REST API page's Compose Address button

Upon clicking the Compose Address button, we'll add the query "verbose=false" to the departments path.
Compose Address dialog

We have now altered the "departments" path to contain the query.
Altered departments path with query

Now, if we had a case where the query should apply to all the requests under the path, then we could model it this way. However, we don't want the query "verbose=false" to apply to our "createDepartment" request. To see that it applies to all requests—even those we don’t want affected—select "(POST) createDepartment" and look at the status line at the bottom of OEPE. The status line indicates the address that will be used for the request.
Status line showing address

Let's back out this change. We can either type control-Z, or click Edit/Undo Set 'Value.'
Edit/Undo Set 'Value' menu pick

Modeling Query Parameters on a Request

At this point, we'll create a new request "getDeptSummaries" on which we'll set a query parameter. To do so, we'll right-click on the Requests folder under the "departments" path and select New/Request.
Create new request from context menu

Enter "getDeptSummaries" in the Name field of the request (leave the Method as GET). We also enter the HTTP Header "Accept=application/json" but I haven’t shown this step. See Modeling a POST Request and Redirection in the REST Service Editor, if you need help with this. It's very similar to how we'll add a query parameter. To add "verbose=false," click the Add button on the Query Parameter tab of the Request.
New request named getDeptSummaries

Enter the name and value in the Add Query Parameter dialog.
Add Query Parameter dialog

We've now set up the query parameter for the request.
verbose=false query parameter

At this point, we can easily see what address will be used for each request. With "(GET) getDeptSummaries" selected in the Outline on the REST API page, the status line is "Address: http://localhost:4545/departments?verbose=false."
status line showing address for getDeptSummaries

With "(GET) getDepartments" selected in the Outline, the status line is simply "Address: http://localhost:4545/departments."
status line showing address for getDeptments

Now, it just remains to set up the output.

Being Precise About Output

For our "getDeptSummaries" request, we want to model that the response will only contain a summary of the information from the departments. To set this up, we click on the Request's Output tab and select Representation for the Type field. This is so we can specify the Output that will be returned in the response.
Output representation

Click the Add button to set up the Representation. In this case, we will be returning Department objects, so we select this for the Data Type. Since there will be more than one department, we check the Multiple box. Finally, since our documentation tells us that the query parameter "verbose=false" will result in returning just a summary of the department information—specifically, the id and name attributes for each department—we uncheck All attributes and select the id and name attributes.
Add Representation dialog

We now have described our "getDeptSummaries" request with some precision.
REST API page showing final model

With this model we can now, for example, generate Java 8 code, which will allow us to programmatically send our "getDeptSummaries" request. The generated code will know how to return just the department summaries due to how we modeled the output representation.

Additional Information

Oracle Enterprise Pack for Eclipse OTN Page

Oracle MAF OTN Page

Oracle MAF on YouTube 

Tuesday Mar 10, 2015

Modeling a POST Request and Redirection in the REST Service Editor

Modeling a POST Request and Redirection in the REST Service Editor

 By Preston Appel

In the blog Introduction to the REST Service Editor, Part 1, we sent a simple GET request to a server and then stored a description of that request and of the JSON payload we received back as a response. This blog is a continuation of that work, but we will be focusing on the REST API page of the editor as we model a POST request to create a department. This POST request involves redirection in that upon sending the request, we receive back a location that is the URI of the newly created department. We'll also see how to test the POST request that we’ve modeled by using the Copy to REST Client functionality.

Getting Up To Speed

To better understand the POST Request, below is a reminder of the description of the request and data types from the Introduction to the REST Service Editor, Part 1 blog. First, the REST Client page shows our "getDepartment" request. It has an HTTP Header: "Accept=application/json" (not pictured), and its Output Representation is a Departments data type.
REST Service Editor's REST API page with original model

The Data Types page shows the top-level Departments data type that we created, which contains multiple instances of the Department data type.
REST Service Editor's Data Types page with original model

We'll create a new request on the REST Client page and use the Department data type in our Output Redirection Representation.

Describing a New POST Request

This blog assumes that we have documentation on the existing REST API that we are describing in the REST Service Editor. Based on that documentation, we will be modeling a POST request to create a new department on the server.

If we were using the REST Client page to send a POST request to the application exposing the REST API, we would use the address "http://localhost:4545/departments." On the REST API page, that address has already been set up with a tree of paths. The root path "http://localhost:4545" has a child path "departments" with a Requests folder. That is where the existing "getDepartments" request was imported. By right-clicking on that Requests folder we can create our new request.
REST API page creating new request

We now set the Method field to POST and type "createDepartment" in the Name field.
REST API page showing new POST request

Based on the documentation of the existing REST API, we know that to create a department on the server, the POST request must have content that is expressed as a JSON payload. We can meet the JSON requirement by adding an HTTP Header "Content-Type=application/json" to the modeled request. To do so we click the Add button and enter the data.
Add Header dialog
HTTP Header created

We now need to model the input of our POST request. After clicking the Input tab of the Request, we select Representation for the Type because we want to send a Department data type for our POST request.
Input Representation creation

We select the Add button and select Department in the Add Representation dialog. By default "All attributes" is checked.
Add Representation dialog

But based on the API's documentation, we cannot send the "id" attribute to the server when creating a new department. Moreover, that documentation for this functionality tells us that we only need to send the "name" attribute to create a new department. So in the dialog we will uncheck "All attributes" and check the "name" attribute.
Add Representation dialog altering attributes

We have now partially described our "createDepartment" request.
Department Input Representation created

Testing the POST Request

We still have to do some work to describe the redirection, but for now, we will test what we have. With "(POST) createDepartment" selected in the Outline of the REST API page, click the Copy to REST Client button for the request.
Copy to REST Client button

This takes us to the REST Client page where we can see that the Method, Address and Headers contain what we have modeled. If, however, we click on the Input tab in the Request Details section, we don't see the Representation we set up. In fact, we only see the option to select a Body type.
REST Client page Input Type

For the current version of the REST Service Editor, the REST Client page only supports an Input of Body. To test our request then, we'll have to do a little more work. Select the Body type and enter {"name":"demo department"} for the value of the body.
REST Client page Body Input Type

Click the Send Request button. The Response section of the REST Client page shows a status of 201 Created, and the Headers section has a Location set to "http://localhost:4545/departments/dep5." This redirection URI allows us to send a GET request for the newly created department.
REST Client page Response

We can either click the arrow button to set the address to the response redirected location or control-click the arrow to send a GET request to the redirected location immediately.
REST Client page Response Status

Here are the results for control-clicking the arrow.
REST Client page redirection URI Response

Describing the Redirection for Our New POST Request

We now return to the REST API page to complete our modeling. With "(POST) createDepartment" selected in the Outline of the REST API page, click on the Output for the Request. Here we select Redirection to describe the behavior that we just demonstrated on the REST Client page.
REST API page Output Redirection

Add "Accept=application/json" to the Headers.
REST API page Output Headers

Add Department to the Representation. Leave "All attributes" checked.
Add Representation dialog

After saving, here's the model we've created of the "createDepartments" POST request.
REST API page showing final model

We now have a model that can, for example, be used to generate Java 8 code. This code will allow us to programmatically send a POST request to create a department and also to process the redirection by sending a GET request to retrieve that new department.

Additional Information

Oracle Enterprise Pack for Eclipse OTN Page

Oracle MAF OTN Page

Oracle MAF on YouTube 

Monday Mar 09, 2015

Oracle at EclipseCon 2015

Its beginning to look a lot like EclipseCon, everywhere you go.

 EclipseCon 2015 is back in the Bay Area and, once again,  Oracle is a Gold Sponsor.

 If you are attending EclipseCon this year, come by the Oracle Booth #18 and say "Hi!". Throughout the week, you will have the opportunity to see demos and chat with team members from Mobile Application Framework, Java, OEPE, Oracle Cloud, and Hudson.

Don't forget to checkout our sessions this week as well


 Date  Title  Speaker  Location
March 10 2015 @ 3:00-3:35PM
iOS Development with Eclipse and Java - Yes it is possible!
Shay Shmeltzer
Sandpebble AB
March 11 2015 @ 7:30-8:30PM
Eclipse and Cloud Hosted Development Platform
Greg Stachnick
Sandpebble AB
March 12 2015 @ 9:00-10:00AM
Keynote: Java 9 and Beyond
Mark Reinhold
Grand Peninsula DEFG

Sunday Mar 08, 2015

Mobile Feature Archive Import and Export with OEPE

Mobile Feature Archive Import and Export with OEPE

By Ian Trimble

Each Mobile Application Framework (MAF) application's view project can be exported as a Mobile Feature Archive (FAR), which can subsequently be imported into other MAF applications.

A Mobile Feature Archive contains all of a view project's artifacts, including features, AMX and HTML pages, and task flows. It also contains information about connections and Cordova plugins, which is application-level information that is exported with a FAR so that the correct application-level information can be merged on FAR import. This application-level information is critical to allowing imported features to work correctly.

Export

To begin export, select File > Export... from the menubar, or right-click in the Project Explorer or on a view project and select Export...

In the Export dialog, select Oracle > Mobile Application Framework > Mobile Feature Archive (FAR), then select Next >
Export dialog

On the Export Mobile Feature Archive (FAR) page, enter or browse for a view project (only view projects are valid for FAR export) and enter or browse for a FAR (this must be a legal pathname for the desired FAR, which has a ".jar" extension.) Select whether or not to include connection details. Create FAR by selecting Finish.
Note: if export was started by right-clicking on a valid view project, it will be pre-populated.
Export Mobile Feature Archive (FAR) page

Import

Importing a FAR is performed in the MAF Application Editor, which can be opened by expanding an assembly project in the Project Explorer and double-clicking MAF Application Editor under the MAF node.

In the MAF Application Editor, there are two ways to begin the import of a Feature Archive:

    1. Right-click the Feature Archives node and select New > Feature Archive. Adding FAR in MAF Application Editor
    2. At the top-right of the MAF Application Editor, select Browse next to the URI field.
    3. Enter or browse for the desired FAR, then select OK. Browse for FAR URI in MAF Application Editor
  1. Drag and drop a FAR from the file-system onto the Feature Archives node.

Importing Connections

To import connections that were defined in the FAR, select the Connections node under the Feature Archive in the MAF Application Editor. Select FAR connections in MAF Application Editor

Connections can be in several different states, both immediately after import and after user actions to decide how to treat each connection. The states are as follows:

  • New: the connection is not already defined in the application and is available for import.
  • Conflicting: there is a conflict between the connection and a connection that is already defined in the application; manual user action will be required to resolve the conflict. The first step in resolving the conflict will be to look at the this connection and the application's connection, to decide how the application's connection could be adjusted to allow import of the connection in the FAR.
  • Partial: the connection is incomplete; manual configuration will be required to make it valid.
  • Not Valid: the connection is somehow invalid; a connection in this state will likely require consultation with the author of the FAR to correct.
  • Equivalent: the connection is equivalent to a connection already defined in the application; import is not necessary.
  • Ignored: the connection has been marked as ignored, usually because it has been determined that the connection is not necessary or that the connection is not valid and so a valid connection has been defined in the application directly.

Select a connection in the list on the right, then select the Import (Import">) button to the right of the list. The connection will now be shown as equivalent, since a corresponding connection has been created in the consuming MAF application. Imported connection in MAF Application Editor
Note: you can also select the Ignore (Ignore) button to the right of the connections list if you choose not to import a connection; this could, however, prevent features in the imported FAR from functioning correctly.

Importing Plug-ins

To import Cordova plugins that were defined in the FAR, select the Plug-ins node under the Feature Archive in the MAF Application Editor. Select FAR Plug-ins in MAF Application Editor

Plugins can be in several different states, both immediately after import and after user actions to decide how to treat each plugin. The states are as follows:

  • New: the plugin is not already defined in the application and is available for import.
  • Equivalent: the plugin is equivalent to a plugin already defined in the application; import is not necessary.
  • Ignored: the plugin has been marked as ignored, usually because it has been determined that the plugin is not necessary or that the plugin is not valid and so a valid plugin has been defined in the application directly.

Select a plugin in the list on the right, then select the Import (Import) button to the right of the list. If this is a new plugin, you must select a URI that points to the equivalent Cordova plugin, since plugin source is not stored in a FAR (only its registration and usage information is stored). The plugin will now be shown as equivalent, since a corresponding plugin registration has been created in the consuming MAF application. Imported plug-in in MAF Application Editor
Note: you can also select the Ignore (Ignore) button to the right of the plugin list if you choose not to import a plugin; this could, however, prevent features in the imported FAR from functioning correctly.

Registering Features

To register features that were defined in the FAR, select the Registered Features node in the MAF Application Editor. Select Registered Features in MAF Application Editor

Select the Browse (Browse) button to the right of the list, then select a feature and click OK. Select feature in dialog

After registering a feature, you may notice that the Plug-in Enablement node shows a warning. This indicates that a registered feature uses a plugin that has not been enabled for use by the application. To remedy this, select the Plug-in Enablement node in the MAF Application Editor. Enable plugins in MAF Application Editor

Select the Enable All button (Enable All) to the right of the list. This will enable all required plugins.
Note: you can also enable individual plugins by selecting the Browse (Browse) button to the right of the list and selecting plugins that you wish to enable. Not enabling plugins could prevent features from functioning correctly.

Additional Information

Oracle Enterprise Pack for Eclipse OTN Page

Oracle MAF OTN Page

Oracle MAF on YouTube 

About

The focus of this blog is on Oracle Enterprise Pack for Eclipse (OEPE) and Oracle's involvement in the Eclipse community. Visit us for information on releases, tips and tricks related to Eclipse, and general Eclipse community information.

Search

Categories
Archives
« July 2016
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today