Friday, December 26, 2014

Fusion Groovy

My goal is to create a UI and call web services.
def vo = ('TroubleTicket_c') 

executeQuery() Executes the view object's query with any
currently applied view criteria filters.
Returns: - void.

def indexes = 1..100
for (j in indexes) {
// do something with j here
}

for (j in 1..100) {
// do something with j here
}

Sunday, October 12, 2014

Useful Links

http://redstack.wordpress.com/
http://venkatnagabhushanam.wordpress.com/2013/09/23/oracle-sales-cloud-fusion-crm-groovy-editor-accomplish-more-by-doing-less/
http://docs.oracle.com/cloud/latest/salescs_gs/FACMI/F1071274AN104B3.htm
http://www.rittmanmead.com/2014/02/groovy-jmx/
http://oraclefusionapplication-crm.blogspot.in/
http://docs.oracle.com/cloud/latest/salescs_gs/CGSAC/groovybasics.htm#sthref8 -- groovy basics
https://search.oracle.com/search/search?search_p_main_operator=all&group=Blogs&q=application%20composer -- application composer search

Application Composer-2- DM model behind custom application

Application Composer Series: Customization Data Storage

Use-Case

This post offers insight into where the records created using custom objects built in Application Composer are stored in the database. For example if you created the Trouble Ticket (TroubleTicket_c) custom object then when your users submit the related creation page, the resulting new records are stored in the tables mentioned below. As such this may be useful information if you are designing custom reports with very specific requirements, or doing more invasive custom development work.
The information provided here is for information only, and should not be considered official documentation. It is intended for query-only use for on-premises development work and all inserting, updating or deleting records directly from any application tables is strictly prohibited and may render your system unsupportable. The information applies to Releases 7 and 8, and does not represent a public API and may change without notice. You can find the formal table definitions in Oracle Enterprise Repository.

The Object Model

All custom objects are registered in the central FND_OBJECTS table and it is for this reason that they cannot be duplicated or reused once registered. When querying this table you'll notice that DATABASE_OBJECT_NAME gives which product table the related records are stored in. Also the CREATED_BY and CREATION_DATE columns in this table can be useful when investigating customization sources.
The detailed definitions for fields, objects, and other Application Composer entries are stored in a combination of MDS and ADF internal structures and tables, and detail on this is outside the scope of this article.

Object Record Tables

Each product provides a [CODE]_REF_ENTITIES table where all its object records are stored, and most have a [CODE]_REF_ENTITIES_XM table for child object records. Note the tables are created only upon creation of the first new object.

CRM Common

  • HZ_REF_ENTITIES - object records
  • HZ_IMP_REF_ENTITIES - used for import

Customer Center

  • ZCX_REF_ENTITIES - object records
  • ZCX_REF_ENTITIES_XM - child object records

Sales

  • MOO_IMP_REF_ENTITIES - used for import 
  • MOO_REF_ENTITIES - object records
  • MOO_REF_ENTITIES_XM - child object records

Marketing

  • MKT_IMP_REF_ENTITIES - used for import
  • MKT_REF_ENTITIES - object records
  • MKT_REF_ENTITIES_XM - child object records

Territories and Quotas

  • MOT_REF_ENTITIES - object records
  • MOT_REF_ENTITIES_XM - child object records
Other similar tables you might notice are intended for alternative (e.g. flex fields) or potential future use, and the reason the Sales Catalog application is not listed here as that does not currently allow creation of custom objects.

Useful Columns

The tables mentioned above have a standardized structure, comprising of some general attribute columns then extensive sets for each supported data type. So if you create an object with three text fields and two number fields, the table will have data for three of the CHAR(1500) columns and two of the NUMBER columns. All these field-related columns are named in the same way, using the following format:
  • EXTN_ATTRIBUTE_[DATATYPE][ID] - where [DATATYPE] is either NUMBER, TIMESTAMP, CHAR, or CLOB, and [ID] is a sequential numeric value.
Examples are EXTN_ATTRIBUTE_CHAR006 (regularly the first custom text field), EXTN_ATTRIBUTE_NUMBER021, EXTN_ATTRIBUTE_TIMESTAMP005, or  EXTN_ATTRIBUTE_CLOB008.
This can make it hard to determine which field on your custom object (e.g. description_c) corresponds to which column (e.g. EXTN_ATTRIBUTE_CHAR015) however the queried values returned should provide a clue, and you can consider looking at the response output (in SDO format) from calling the related custom object web servicesdiscussed here. Some other important columns that provide useful values for queries include: ID as the internal primary key of the table (e.g. 300000002763453), the RECORD_NAME as given in the create object page in Application Composer and ATTRIBUTE_CATEGORY as the object API name to which this record belongs (e.g. TERROBJ1_c below).

Application Composer-1

Application Composer Series: An Introduction To Global Functions

Global Functions allow you to create common utility code programs that you can call from the custom triggers and workflows added in Application Composer. Global Functions help increase the modularity and clean design for your customizations, allowing them to be easier to understand and maintain going forwards.
If you've not seen this feature before, check out this simple video demonstration from our YouTube channel.
To help illustrate how these fit into the overall Application Composer architecture, the following simple diagram shows how Object Functions are available in the context of only each object (e.g. Opportunities) whereas Global Functions are available across applications for use in code within object events (such as triggers and buttons) and in object functions.

Usage Tips

  • There are no seeded Global Functions at this time (the diagram above gives suggestions only), however we are looking at building a library of common utility code. More to come on this.
  • Global Functions support a wide use of input parameters and return types. These are: String, Long, Double, Date, Boolean, Object, List, and Map.
  • To use your current view object instance (e.g. Opportunity 1234) you can pass it as an input variable.
  • Release 9 introduces validation of known high-risk API's to avoid using in your groovy scripts. The recommended API libraries to use are documented here.
  • Global Functions can only be created using Application Composer and to prevent problems it does not support uploading file libraries or code artifacts into the system.

Illustrative Example

The following Global Function is taken from the integration example for Sales Cloud with E-Business Suite (Doc ID 1620455.1), which uses an extensive library of Global Functions. As you can see it searches for Sales Accounts, returning the object for use in the calling code. It also uses other global functions as well, including O_INT_ApplyFilter for manipulating the view criteria and two more for logging operations in the catch block.

Groovy Scripts- Season-1

https://blogs.oracle.com/fadevrel/entry/application_composer_series_where_you

Application Composer Series: Where and When to use Groovy

This brief post is really intended as more of a reference than an article. The table below highlights two things, firstly where you can add you own custom logic via groovy code (end column), and secondly (middle column) when you might use each particular feature. Obviously this applies only where Application Composer exists, namely Fusion CRM and Oracle Sales Cloud, and is based on current (release 8) functionality.
FeatureMost Common Use Case Groovy
Field TriggersReact to run-time data changes. Only fired when the field is changed and upon submit.Y
Object TriggersTo extend the standard processing logic for an object, based on record creation, updates and deletes. There is a split between these firing events, with some related to UI/ADF actions and others originating in the database.
UI Trigger Points:
  • After Create - fires when a new object record is created. Commonly used to set default values for fields.
  • Before Modify - Fires when the end-user tries to modify a field value. Could be used for generic warnings or extra security logic.
  • Before Invalidate - Fires on the parent object when one of its child object records is created, updated, or deleted. For building in relationship logic.
  • Before Remove - Fires when an attempt is made to delete an object record. Can be used to create conditions that prevent deletes.
Database Trigger Points: 
  • Before Insert in Database - Fires before a new object is inserted into the database. Can be used to ensure a dependent record exists or check for duplicates.
  • After Insert in Database - Fires after a new object is inserted into the database. Could be used to create a complementary record.
  • Before Update in Database -Fires before an existing object is modified in the database. Could be used to check dependent record values.
  • After Update in Database - Fires after an existing object is modified in the database. Could be used to update a complementary record.
  • Before Delete in Database - Fires before an existing object is deleted from the database. Could be used to check dependent record values.
  • After Delete in Database - Fires after an existing object is deleted from the database. Could be used to remove dependent records.
  • After Commit in Database - Fires after the change pending for the current object (insert, update, delete) is made permanent in the current transaction. Could be used when committed data that has passed all validation is required.
  • After Changes Posted to Database - Fires after all changes have been posted to the database, but before they are permanently committed. Could be used to make additional changes that will be saved as part of the current transaction.
Y
Field ValidationDisplays a user entered error message based groovy logic validating the field value. The message is shown only when the validation logic returns false, and the logic is triggered only when tabbing out of the field on the user interface. Y
Object ValidationCommonly used where validation is needed across multiple related fields on the object. Triggered on the submit UI action.Y
Object WorkflowsAll Object Workflows are fired upon either record creation or update, along with the option of adding a custom groovy firing condition.Y

Field Updates - change another field when a specified one changes. Intended as an easy way to set different run-time values (e.g. pick values for LOV's) plus the value field permits groovy logic entry.Y

E-Mail Notification - sends an email notification to specified users/roles. Templates support using run-time value tokens and rich text.N

Task Creation - for adding standard tasks for use in the worklist functionality.N

Outbound Message - will create and send an XML payload of the related object SDO to a specified endpoint.N

Business Process Flow - intended for approval using the seeded process, however can also trigger custom BPMN flows.N
Global FunctionsUtility functions that can be called from any groovy code in Application Composer (across applications). Y
Object FunctionsUtility functions that are local to the parent object. Usually triggered from within 'Buttons and Actions' definitions in Application Composer, although can be called from other code for that object (e.g. from a trigger).Y
Add Custom FieldsWhen adding custom fields there are a few places you can include groovy logic.Y

Default Value - to add logic within setting the default value when new records are entered.Y

Conditionally Updateable - to add logic to set the field to read-only or not.Y

Conditionally Required - to add logic to set the field to required or not.Y

Formula Field - Used to provide a new aggregate field that is entirely based on groovy logic and other field values.Y
Simplified UI Layouts - Advanced ExpressionsUsed for creating dynamic layouts for simplified UI pages where fields and regions show/hide based on run-time context values and logic. Also includes support for the depends-on feature as a trigger.Y

Thursday, October 9, 2014

FIC useful Links

Wednesday, October 8, 2014

FlexField--1

Administrators configure flexfield segments to capture data that represents the values of attributes. Flexfield segments represent attributes of entities (business objects). Most business objects are enabled for descriptive flexfields. Some business objects are enabled for extensible flexfields.
For example, an airline manufacturer might require very specific attributes for their orders that aren't provided by the out-of-the-box implementation of an order. Because a flexfield exists for the order business object, you can use it to create and configure the desired attribute.
The figure shows the layers of a flexfield: the business entity table and metadata in the database, business components that are Application Development Framework (ADF) objects or ADF business component (ADFbc) objects derived from the metadata and stored in the Metadata Services Repository (MDS), and the user interface where the input fields defined by the flexfield segments are rendered. The flexfield definition consists of all the metadata defined during configuration and stored in the database.
The figure follows flexfield development from adding
capacity in the database to enable flexfield segments through applications
development creating the flexfield and administrators configuring
the flexfield so the definition is stored in the database and the
business components are deployed to the Metadata Services repository,
which makes the attributes representing the flexfields available in
the user interface accessing those business components.
Application developers create a flexfield and register it so that it is available for configuration. Administrators and implementation consultants configure segments and other properties of the available flexfields. This information is stored as additional flexfield metadata in the database. Deploying the flexfield generates ADF business components based on the flexfield metadata in the database.
The following aspects are important in understanding how flexfields and Oracle Fusion Applications architecture work together:
  • Integration
  • Deployment
  • Import and Export
  • Runtime
  • Patching

Integration

The attributes that you add by configuring flexfields are available throughout the Oracle Fusion Middleware technology stack, allowing the flexfields to be used in user interface pages, incorporated into the service-oriented architecture (SOA) infrastructure, and, in the case of descriptive flexfields, integrated with Oracle Business Intelligence. You identify flexfield segments for integration by the segment's Application Programming Interface (API) name.
A flexfield affects the Web Services Description Language (WSDL) schemas exposed by ADF services and used by SOAcomposites. The Web services that expose base entity data also expose flexfield segment data.
Attributes incorporate into SOA infrastructure (BPEL, Rules) and integrate with business intelligence (Oracle Business Intelligence, Extended Spread Sheet Database (ESSbase)).
Flexfield configurations are preserved across Oracle Fusion Applications updates.

Deployment

The metadata for the flexfield is stored in the application database as soon as you save your configuration changes. Deploying the flexfield generates the ADF business components so that the runtime user interface reflects the latest definition of the flexfield in the metadata.

Importing and Exporting

You can export and import flexfields with a deployment status of Deployed or Deployed to Sandbox across instances of Oracle Fusion Applications using the Setup and Maintenance Overview page. Ensure a flexfield is eligible for migration (by verifying that it has successfully deployed) prior to attempting the migration.

Runtime

For a flexfield to reflect the latest flexfield definition at runtime it must be deployed. The user interface accesses a business object and the deployed flexfield definition indicates which business object attributes the flexfield captures values for. If you add display customizations for a flexfield using Oracle Composer, these are customizations on the page so that the same flexfield segments can appear differently on various different pages.
Values entered for segments are validated using value sets.

Patching

Flexfield configurations are preserved during patching and upgrading.

FlexFields

Incentive Compensation Base Transaction Descriptive Flexfield: Explained


Use Base Transaction incentive compensation descriptive flexfield global segments to store transaction attributes that do not exist by default in the CN_TP_TRANSACTIONS_ALL table.
The global segment data types VARCHAR2 and NUMBER have the following customizable attributes available for immediate use.
Data Type
Attributes
VARCHAR2 (240 CHAR)
ATTRIBUTE1 - ATTRIBUTE150
NUMBER
ATTRIBUTE_NUMBER1 -- ATTRIBUTE_NUMBER50
In the Setup and Maintenance work area:
  • Use the Manage Incentive Compensation Descriptive Flexfield task to configure one or more global segments, including associating any relevant value sets or lookups, and deploy the Base Transaction descriptive flexfield.
  • Use the Configure Tables and Columns task to enable the global segments for use in the calculation process.
  • Use the Manage Custom Rule Qualifiers task to enable the global segments for use in the crediting and classification processes.
======================
Why did my flexfield changes not appear in the runtime UI?
The ADF business components or artifacts of a flexfield, which are generated into an metadata services (MDS) repository when the flexfield is deployed, are cached within a user session. You must sign out and sign back in again to view flexfield definition changes reflected in the runtime application user interface page.
A flexfield's deployment status indicates whether the flexfield segments as currently defined in the metadata are available to end users. The flexfield segments seen by end users in the runtime correspond to the flexfield definition that was last deployed successfully.
=================




deployment status indicates how the flexfield metadata definition in the Oracle Fusion Applications database relates to the Application Development Framework (ADF) business components generated into a Metadata Services (MDS) repository.
The following aspects are important in understanding how flexfield deployment status is calculated:
  • Settings that affect flexfield deployment status
  • How deployment status is calculated

Settings That Affect Flexfield Deployment Status

If you have made a change to a flexfield and expect a changed deployment status, be sure you have saved your changes. No settings affect flexfield deployment status.

How Deployment Status Is Calculated

If the flexfield definition has been edited through the Define Flexfields activity task flows, the status is Edited. The latest flexfield metadata definition in the Oracle Fusion application diverges from the latest deployed flexfield definition. Any change, including if a value set used in a flexfield changes, changes the deployment status to Edited. If a flexfield has never been deployed, its status is Edited.


=================
Why did the extensible flexfield context not appear at runtime?
If a deployed extensible flexfield context doesn't appear in the user interface, verify that the context is associated with one of the category's pages defined for the extensible flexfield.
=================
Defining and driving segment values

To populate a flexfield segment with a default value when a row is created, specify a default type of constant or parameter and a default value.
To synchronize a segment's value with another field's value whenever it changes, specify the derivation value to be the flexfield parameter from which to derive the attribute's value. Whenever the parameter value changes, the attribute's value is changed to match. If you derive an attribute from a parameter, consider making the attribute read-only, as values entered by users are lost whenever the parameter value changes.
When defaulting or deriving a default value from a parameter, only those attributes designated by development as parameters are available to be chosen.
Different combinations of making the segments read only or editable in combination with the default or derivation value or both, have different effects.
Initial runtime behavior corresponds to the row for the attribute value being created in the entity table. If the default value is read only, it cannot subsequently be changed through the user interface. If the default value isn't read only, users can modify it. However, if the segment value is a derived value, a user-modified segment value is overwritten when the derivation value changes.
Default Type
Default value specified?
Derivation value specified?
Initial runtime behavior
Runtime behavior after parameter changes
None
No
Yes
No initial segment value
The changed parameter derivation value updates segment value
Constant
Yes
No
Default segment value
N/A
Constant
Yes
Yes
Default segment value
The changed parameter derivation value updates segment value
Parameter
Yes
No
The default segment value is the parameter's default value
N/A
Parameter
Yes
Yes, and same as default value
The default segment value is the parameter's default and derivation value
The changed parameter derivation value updates segment value
Parameter
Yes
Yes, and different from default value
The default segment value is the parameter's default value
The changed parameter default value doesn't update segment value. Only the changed derivation value updates the segment value.
====================