By: Greg Becker | Splunk Consultant, Team Lead

 

During a recent project, a customer had business units that had a requirement to provide more granular security in the Documents hierarchy than the out-of-the-box WebCenter Portal 12c product can accommodate. For this project, we used the security features that are available within WebCenter Content using document accounts and security groups. With this approach, all that we had to do was configure a unique folder entry point from Portal into Framework Folders within Content and the remainder was simply configurations within WCC. The remainder of this document outlines that process.

This approach requires configurations in various locations:

1. Group membership in the Identity Management store
2. Security Accounts and Security Groups in WebCenter Content
3. Credential map settings in WebCenter Content
4. Folder security settings in WebCenter Content

 

Group Membership:

From an Administrative perspective (AD/LDAP)

• Create the new AD/LDAP group naming, come up with a consistent naming convention and use any existing suggestions from the AD/LDAP team
• Get the groups created and assign users to the groups.

1. Login to the appropriate Identity Management tool
2. Create a new group and assign users to that group
   1. Name the new group
   2. Assign users to the new group
   3. Click “Create” to create the new group with selected users
   4. Repeat for any additional groups that are required

 

Create the new Security Accounts in WebCenter Content:

1. Login to WebCenter Content as an administrator
2. Navigate to Administration -> Admin Applets
3. Start the User Admin applet
4. Choose Security -> Predefined Accounts

5. Add the new accounts to accommodate the defined folder structure. Below is an example structure:

 

Update the Credential Map in WebCenter Content:

1. Login to WebCenter Content as an administrator
2. Navigate to Administration -> Credential Maps
3. Choose the appropriate credential map to modify
4. In this example we will copy the Allowancing section and make the appropriate edits (this is where the IdM group maps to UCM accounts and security groups)

5. Add the new entries for the new folder

6. Click Update to save

 

Add the new folder with security attributes in Content UI for WebCenter Content:

1. Login to WebCenter Content UI as an administrator (https://<WebCenter Portal>/wcc/faces/wccmain)
2. Navigate to the appropriate top-level folder already assigned to the portal that you are working with:

3. Click the icon in the upper right to create a new folder

4. Name the folder HAZMAT and click Save

5. In the folder tree right-click on the new folder and choose Properties to modify the security for the folder

6. In the Folder Properties dialog box switch to the Security tab and ensure that the new account is selected and then click Save

 

Validation

At this point, you should be able to login with the users that you assigned to the new group in IdM and verify that they see the appropriate new folder. Logging in with the new user shows the following folder result:

 

Specify the starting folder within WebCenter Content:

When you have created your folders and set permissions within WebCenter Content you can then specify the starting folder within your Portal – this is the key to taking advantage of the custom security. The following image shows where the configuration happens for the Content Manager.

 

Migration:

After you have configured this solution in a test environment you can use the following guidelines to migrate from one environment to another.

• Migrate AD/LDAP groups and user configs as needed
• Use CMU bundles inside Content to migrate security accounts (or re-create manually)
• Copy over Credential Map
• Use Archiver to move the folder structure to PROD
• Use Archiver to move the entire batch of content if it was moved into the TEST environment
  • Alternatively, only do some test content and only contribute ‘real’ content when PROD is ready
• Validate

 

Want to learn more about custom document security in Oracle WebCenter Portal 12c? Contact us today!

By: Greg Moler | Director of Imaging Solutions

 

Does your organization utilize Oracle Fusion Applications such as Oracle Cloud ERP, Cloud Human Capital Management, and Project Portfolio Management cloud?  Are you looking for ways to extend the functionality of these applications?  These platforms store a lot of critical business data, much of which has the potential to be integrated with other third-party applications.  In this article, we explore use cases and considerations for leveraging Oracle BI reports to integrate Oracle Fusion data with external applications.

 

What are Oracle BI reports?

Oracle’s Fusion Applications including Cloud ERP, Cloud Human Capital Management, and Project Portfolio Management cloud as well as many others, use the Oracle Business Intelligence (BI) platform to provide reports and analytics.  BI reports provide a way to query and report against the underlying data in these platforms.  In the cloud platform, these take the place of traditional database queries.  They can be used in a variety of different functions to extract data for use with external applications.

 

Use Cases

When it comes to potential use cases for extending your Oracle Fusion application’s data, the possibilities are endless.  If you can think of a need, we can design a way to build it.  In this section, we take a glimpse at some specific use cases for integrating data from Oracle Cloud ERP.

• Automating GL/Project Account Coding: Manually coding invoices can be time-consuming for AP personnel. This process can be streamlined by automating business logic to programmatically apply GL and Project codes to invoices.  For example, often one attribute on the invoices drives the rest of the coding.  Another common scenario is vendor distribution sets, where each vendor has a pre-defined set of charge account strings and percentages that get applied to each invoice.  BI reports can be structured to take input from your 3^rd party application such as vendor id and return coding data.
• Workflow routing and Approval hierarchy: If your application does workflow routing or approval hierarchy, it will need to know which user’s documents should be assigned to. Often, this is based on data on the document and can be retrieved from Cloud ERP.  BI reports can be designed to return the appropriate workflow assignee based on the pertinent ERP data.  If your organization also utilizes Oracle Human Capital Management (HCM), you can extend functionality even further by directly accessing employee data in the approval hierarchy.
• Vendor data: Vendor data stored in Oracle Cloud ERP can be incredibly useful in a variety of different scenarios. For example, vendor identification on invoices, purchase orders, and other documents.  Another common use case is the use of vendor-specific attributes or descriptive flex fields (dffs) defined in Cloud ERP.  These attributes can be easily maintained by the business in the Fusion interface and leveraged in an external application to drive automation such as account coding or workflow routing as described previously.
• Validation data: More than likely, your application will need to be able to validate that the data on the document or object is correct before allowing it to proceed. The information needed to perform this validation is typically stored in Cloud ERP.  For example, validating whether a purchase order had enough open balance available for a line item.  BI reports provide a way to perform these validations, simply by taking input parameters from the external application and returning corresponding data from cloud Fusion.
• Reporting data: Reporting options within Fusion Applications and Oracle Business Intelligence platform can be limited. These reporting capabilities can be supplemented by an external reporting tool.  BI reports provide a way to extract data out of Oracle for analysis and reporting in an outside application.

 

 Considerations when creating Oracle BI Reports:

When designing and creating Oracle BI reports for integration with an external application, there are many considerations including:

• Data Structure: Design a reusable format for your BI reports so that data is returned in a consistent structure. This will simplify integration points with the reports.
• Data return type: What return data type will your application require? XML? CSV?
• Catalog folder structure: Consider how to organize your catalog folder structure. Which reports function together and should be grouped together?  Which reports should be promoted together between environments?  The easiest way to migrate reports is to use the Archive/Unarchive function on an entire folder.  It is important to consider which reports should be archived together.
• Testing options: The most basic way to test the BI reports is through the Fusion Catalog Manger. This provides a good baseline test.  More than likely, the reports will be called via web service, so the next layer of testing should be done using a tool such as SOAP UI that will allow you to test calling web services.  This will allow you to call the web service and view responses as they will be received by the external application.  Keep in mind that all responses must be decoded before they can be consumed.

 

Interested in getting more out of your Cloud ERP data?  Contact TekStream to learn about how we can assist with your Cloud Fusion integration needs!

It’s no secret that Oracle licensing can be complicated. Between the never-ending legal jargon, Core calculations, and usage analysis, Oracle licensing can get complex. Often, it’s navigating these licenses, not the underlying technology, that can halt even the most well-intentioned Oracle Cloud migration efforts.

In this blog post, we’re going to take a closer look at how you can leverage your existing Oracle license to support your Oracle Cloud migration efforts to either Oracle Cloud Infrastructure (OCI) or Amazon Web Services (AWS).

What is a Bring Your Own License Model, Anyway?

Simply put, Bring Your Own License (BYOL) is a licensing model that lets you utilize your current on-premise Oracle license to support your Oracle migration and deployment to the Cloud – oftentimes at a significant cost savings.

BYOL on OCI

Is your organization leaning toward migrating your legacy Oracle system to OCI? If you have any existing Oracle software licenses for services like Oracle Database, Oracle Middleware, or Oracle Business Intelligence, you can leverage those existing licenses when subscribing to Oracle Platform Cloud Services (Oracle PaaS).

With BYOL, you can leverage existing software licenses for Oracle PaaS subscriptions at a lower cost. As an example, if you already have a perpetual license for Oracle Database Standard Edition, then you can leverage that license to purchase a cloud subscription to Standard Edition Database as a Service at a lower cost.

The total cost of ownership calculations can be complex with this option as you need to consider your existing cost of support, the added value you will gain from a cloud-based, self-healing, self-patching solution versus the cost of buying the solution outright without using BYOL. TekStream can help you weigh these options if you are thinking about leveraging BYOL for your cloud journey.

How Do You Use Your BYOL for Oracle PaaS?

So, how exactly do you use your existing Oracle software license to support your OCI migration needs? It’s easier than you may think:

• Select specific Oracle BYOL options in the Cost Estimator to get your BYOL pricing.

• Apply your BYOL pricing to individual cloud service instances when creating a new instance of your PaaS service. BYOL is the default licensing option during instance creation for all services that support it.

As noted, when creating a new instance of Oracle Database Cloud Service using the QuickStart wizard, the BYOL option is automatically applied.

Bring Your Own License to AWS

Oracle can be deployed on AWS using the compute resources (EC2). Like a standard server on your datacenter today, when using this migration strategy, you are responsible for the licenses of any software running on the instances (including Oracle database, middleware, or any other software instances).

You can use your existing Oracle licenses to run on AWS. If you choose this licensing approach, it is important to consider a couple of supporting factors.

If you are licensing a product by processor or named users on this platform, you need to consider the Oracle core multipliers referenced in the terms and conditions of your license agreement.

If you are using employee or user-based metrics, you can deploy solutions on AWS with little concern about these issues.

Many Oracle Unlimited and Enterprise License Agreements do not allow usage in AWS. If you are using one of these options for your Oracle licensing, we would recommend reviewing your contracts carefully before deploying these Oracle licenses on AWS.

Is the BYOL Licensing Model Right for You?

Regardless of which Cloud platform you choose (AWS or OCI), a Cloud migration is the perfect opportunity to reexamine your Oracle license structure. Whether you opt for the BYOL licensing model or choose to utilize a new licensing structure, take this opportunity to identify ways to reduce the cost of your overarching licensing structure.

Learn about alternative licensing models by downloading our free eBook, “A Primer on Licensing Options, Issues, and Strategies for Running Oracle CPU-based Licenses on Cloud.”

Need help? TekStream can help demystify the Oracle licensing process. We provide straightforward counsel and, most importantly, identify cost-saving opportunities while still maintaining full licensing compliance.

 

If you’d like to talk to someone from our team, fill out the form below.

By: William Phelps | Senior Technical Architect

 

When using Oracle Forms Recognition(“OFR”)  or WebCenter Forms Recognition(“WFR”) with the Oracle Solution Accelerator or Inspyrus, clients often engage consulting companies (like TekStream) to fine-tune extraction of invoice data.  Depending on the desired data to extract from the invoice, the terms “confidence”, “training”, and “scripting” are often used in discussing and designing the solution.  While these techniques justifiably have their place, it may be overkill in many situations.

Chances are, if you are reading this article, that you may already be using WFR.  However, the extraction isn’t as good as desired.  You may have been using it for quite a while, with less-than-optimal results.

In reality, there are several no-cost options that a customer can (and should) perform before considering ANY changes to a WFR project file or attempting to bring in consulting.  This approach is the “don’t step over a dollar to pick up a dime” approach.  Many seemingly impossible extraction issues are truly and purely data-related, and in all likelihood, these basic steps are going to be needed anyway as part of any solution.  There is a much greater potential return on investment by simply doing the boring work of data cleanup before engaging consulting.

The areas for free improvement should begin by answering the following questions:

1. Does the vendor address data found in the ERP match the address for the vendor found on the actual invoice image?
2. Is the vendor-defined in the ERP designated as a valid pay site?
3. In the vendor data, are intercompany and employee vendors correctly marked/identified?
4. Do you know the basic characteristics of a PO number used by your company?
5. Are the vendors simply sending bad quality invoice images?

Vendor Address Considerations

The absolute biggest free boost that a customer can do to increase extraction is to actually look at the invoice image for the vendor, and compare the address found on the invoice to the information stored in the ERP.  WFR looks at the zip code and address line as key information points.  Mismatches in the ERP data will lower the extraction success rate.  This affects both PO and non-PO invoice vendor extraction from an invoice.

To illustrate this point at a high level, let’s use some basic data tools found within the Oracle database for testing.  The “utl_match” packages will work to get a basic feel for how seemingly minor string differences can affect calculations.

Using utl.match.edit_distance_similarity in a simple query, two strings can be compared as to how similar the first string is to the second.  A higher return value indicates a closer match.

• This first example shows the result when a string (“expresso”) is compared to itself, which unsurprisingly returns 100.

• Changing just one letter can affect the calculation in a negative direction. Here, the second letter of the word is changed from an “x” to an “s”.  Note the decrease in the calculation.

• The case in the words can matter to a degree as well for this comparison. Simply changing the first letter to uppercase will result in a similar reduction.

• Using the Jaro Winkler function, which tries to account for data entry errors, the results are slightly better when changing from “x” to “s”.

Let’s now move away from theory.  In more of a real-world example, consider the following zip code strings, where the first zip code is a zip + 4 that may be found on the invoice by WFR, and the second zip code is the actual value recorded in the ERP.

In the distance similarity test, the determination is that the strings are 50/50 in resemblance.

However, Jaro Winkler is a bit more forgiving.  There is a difference, but it’s closer to matching both values.

The illustrations above are purely representative and do not reflect the exact process used by WFR to assign “confidence”.  However, it’s a very good illustration to visually highlight the impact of data accuracy.

The takeaway from this ERP data quality discussion should be that small differences in data between what appears on the invoice compared to the data found in the ERP matters.  This data cleanup is “free” in the sense that the customer can (and should) undertake this operation without using consulting dollars.

Both the Inspyrus and Oracle Accelerator implementation of the WFR project leverage a custom vendor view in the ERP.

• Making sure this view returns all of the valid vendors is critical for correct identification of the vendor. A vendor that is not found in this view cannot be found by WFR – plain and simple since the WFR process collects and stores the vendor information for processing.
• Also, be sure in this view to filter out intercompany and employee vendor records. These vendor types are typically handled differently, and the addresses of these kinds of vendors typically appear as the bill-to address on an invoice.  Your company address appearing multiple times on the invoice can lead to false positives.
• In EBS, there is a concept of “pay sites”. A “pay site” is where the vendor/vendor site combination is valid for accepting payments and purchases.  Be sure to either configure the vendor/vendor site combination as a pay site, or look to remove the vendor from the vendor view.

PO Number Considerations

On a similar path, take a good look at your purchase order number information.  WFR operates on the concept of looking for string patterns that may/may not be representative of your organization’s PO number structure.  For example, when describing the characteristics of your company’s PO numbers, these are some basic questions you should answer:

• How long are our PO numbers? 3 characters? 4 characters? 5 or more characters? A mix?  What is that mix?
• Do our PO numbers contain just digits? Or letters and digits? Other special characters?
• Do our PO numbers start with a certain sequence? For example, do our PO numbers always start with 2 random letters? Or two fixed letters like “AB”? Or three characters like “X2Z”?

Answering this seeming basic set of questions allows WFR to be configured to only consider the valid combinations.

• By discarding the noise candidates, better identification and extraction of PO number data can occur.
• More accurate PO number extractions can lead to increased efficiency inline data extraction, since the PO data from the ERP can be leveraged/paired, and can lead to better vendor extraction since the vendor can be set based on the PO number.

Avoid trying to be too general with this exercise.  Trying to cast too wide of a net will actually make things worse.  Simply saying “our PO numbers are all numbers 7 to 10 digits long” will result in configurations that pick up zip codes, telephone numbers, and other noise strings. If the number of variations is too many, concentrate on vendors using the 80/20 rule, where 80% of the invoices come from 20% of the vendor base.

General Invoice Quality

Now, one might think “I cannot tell the vendor what kind of invoice to send.”  That’s not an accurate statement at all.  If explained correctly, and provided with a proper incentive, the vendor will typically work to send better invoices.  WFR is very forgiving, but not perfect, and looking at the items in the following list will help.

• Concentrate initially on the vendors who send in high volumes of invoices.
• Make sure the invoices are good quality images containing no extra markings on the image that is covering key data, like PO numbers, invoice numbers, dates, total amount, etc.
• Types of marks could be handwriting, customs stamps, tax identification stamps, mailroom stamps, or other non-typed or machine-generated characters. Dirty rollers on scanners can leave a line across the image.

Hopefully, this article will give an idea of the free things that can be done to increase the efficiency of WFR.

Want to learn more? Contact us today!