How to use Visual Builder to Create Public Facing Functionality for Sites

By: Courtney Dooley | Technical Architect


Content and Experience Cloud form functionality such as Contact Us, Feedback, and Survey information is not offered out of the box.  In fact, developing these forms and functionality can sometimes require additional services to be purchased or custom development to be implemented.  But if you have Integration Cloud Service, you may not realize that Visual Builder offers a publically accessible form and process that can be used by sites built within Oracle Content and Experience Cloud.

Visual Builder

Visual Builder is a Platform as a Service (PaaS) cloud-based solution that offers the ability to create Web Applications, Mobile Applications, define Service Connections and even integrate with Process Cloud.  Although many of these functions will require authentication, Visual Builder does have the unique option for publically accessible applications.  In the Feedback use case, we will use Business Objects to define and handle the feedback functionality for public-facing sites.  Although this functionality could be handled using a Web or Mobile Application, business objects are quick to set up and configure.

Building Options

The main menu of Visual Builder displays the options below.

  • Mobile Applications
  • Web Applications
  • Service Connections
  • Business Objects
  • Components
  • Processes – Integration with Oracle Integration Cloud Process Applications

For both the Mobile and Web Applications, form development and data structure is available for customization and modification to meet the needs of any service.

Additional services can be configured within the Service Connections then called by a form function or workflow.  These services can be selected from a catalog of predefined services, a specification document that defines the service, or by specifying the endpoint for the service.

Components are elements which can be added to a form such as Images, Text, Buttons, Menus, and Links.  Field types such as dropdowns, text inputs, rich text, and specific field types such as Currency, Email, Phone etc. are all available out of the box.

Business Objects

A quick and easy way to create a public service is by creating a Business Object.

  • Overview – besides general properties, relationships can be established to other business objects for other services.
  • Fields – define information to be received and used within the service including audit fields such as creationDate, createdBy etc.
  • Security – set the authentication needed for the service. In the case of a public service, selecting Anonymous User permissions allow for public access.

  • Business Rules – define how to handle the information being provided, below are the types of handlers which can be defined.
    • Object Triggers – we will use this one in our Feedback Use Case
    • Field Triggers
    • Object Validators
    • Field Validators
    • Object Functions
  • Endpoints – a base set of API endpoints created automatically when the Business Object is created


  • Data – shows all processed data for development, staging, and live processes including the ability to query specific data.


Feedback Use Case

For a simple Feedback Form that can be made public in Content and Experience Sites, we created the Business Object, as described in the previous section.  We then specify the fields we expect from the Feedback form and configure their properties for requirement, uniqueness, and searchability.

Lastly, we add an Object Triggered business rule that executes before a new feedback form is inserted.  This Business Rule will simply send the feedback data to a specific email inbox.


New Actions can be added by clicking on the plus sign within the process flow diagram, then configuring the action to take.

The Email information can be configured by clicking the edit pencil on the Action.  The Email address can be a set value as shown below, or it can be an expression where the value is derived from a service or other data.

Once the business object is configured and saved, the form to present on the site can be created one of two ways.

  1. Create a Web Application that provides the form and on submit inserts the business object which will process the notification. This form would then be presented to users via I-Frame.
  2. Create the form on a Content and Experience Cloud layout or custom component which calls the Visual Builder Cloud Service API for that business object on submit.

The Feedback service will not be available until it has been Staged then Deployed, but once deployed, it should be available for use on any public-facing site.

Contact us for more tips and tricks on developing Oracle Visual Builder Cloud Service Applications!

How to Filter Out Events at the Indexer by Date in Splunk

By: Jon Walthour | Splunk Consultant


A customer presented me with the following problem recently. He needed to be able to exclude events older than a specified time from being indexed in Splunk. His requirement was more precise than excluding events older than so many days ago. He was also dealing with streaming data coming in through an HTTP Event Collector (HEC). So, his data was not file-based, where an “ignoreOlderThan” setting in an inputs.conf file on a forwarder would solve his problem.

As I thought about his problem, I agreed with him—using “ignoreOlderThan” was not an option. Besides, this would work only based on the modification timestamp of a monitored file, not on the events themselves within that file. The solution to his problem needed to be more granular, more precise.

We needed a way to exclude events from being indexed into Splunk through whatever means they were arriving at the parsing layer (from a universal forwarder, via syslog or HEC) based on a precise definition of a time. This meant that it had to be more exact than a certain number of days ago (as in, for example, the “MAX_DAYS_AGO” setting in props.conf).

To meet his regulatory requirements for retention, my customer needed to be able to exclude, for example, events older than January 1 at midnight and do so with certainty.

As I set about finding (or creating) a solution, I found “INGEST_EVAL,” a setting in transforms.conf. This setting was introduced in version 7.2. It runs an eval expression at index-time on the parsing (indexing) tier in a similar (though not identical) way as a search-time eval expression works. The biggest difference with this new eval statement is that it is run in the indexing pipeline and any new fields created by it become indexed fields rather than search-time fields. These fields are stored in the rawdata journal of the index.

However, what if I could do an “if-then” type of statement in an eval that would change the value of a current field? What if I could evaluate the timestamp of the event, determine if it’s older than a given epoch date and change the queue the event was in from the indexing queue (“indexQueue”) to oblivion (“nullQueue”)?

I found some examples of this in Splunk’s documentation, but none of them worked for this specific use case. I also found that “INGEST_EVAL” is rather limited in what functions it can work with the eval statement. Functions like “relative_time()” and “now()” don’t work. I also found that, at the point in the ingestion pipeline where Splunk runs these INGEST_EVAL statements, fields like “_indextime” aren’t yet defined. This left me with using an older “time()” function. So, when you’re working with this feature in the future, be sure to test your eval expression carefully as not all functions have been fully evaluated in the documentation yet.


Here’s what I came up with:






INGEST_EVAL = queue=if(substr(tostring(1577836800-_time),1,1)=”-“, “indexQueue”, “nullQueue”)


The key is in the evaluation of the first character of the subtraction in the “queue=” calculation. A negative number yields a “-” for the first character; a positive number a digit. Generally, negative numbers are “younger than” your criteria and positive numbers are “older than” it. You keep the younger events by sending them to the indexQueue (by setting “queue” equal to “indexQueue”) and you chuck older events by sending them to the nullQueue (by setting “queue” equal to “nullQueue”).

Needless to say, my customer was pleased with the solution we provided. It addressed his use case “precisely.” I hope it is helpful for you, too. Happy Splunking!

Have a unique use case you would like our Splunk experts to help you with? Contact us today!