Wednesday, August 30, 2017

#595 XPaaS - Using PCS to on-board new API Platform users



Self-registration is on the roadmap for API Platform CS, in the meantime, you can easily use PCS to do the onboarding for you.

Here is a simple scenario -


Internal folks should be able to register for one of the following roles -

  • API Developers
  • API Managers
  • Gateway Managers
A manager will then approve/reject such requests.

So what do we need to implement this?

1. A data entry form
2. A REST service to create a user in the Identity Mgt system of APIP CS.
3. A REST service to assign one of the APIP CS roles to the newly created user.


All of this can be done very easily in PCS.


Here is the form that kicks off the process- 



Here is the PCS Connector to my APIP CS Identity Mgt system - I use the REST API to
interface with this.























As you can see, there are 2 resources - createUser and addUser2Group - self explanatory!

Here is the basic PCS process - Somebody requests access to APIP CS. Another person, our
API Manager, will approve or reject this request. The user is created and assigned the selected
APIP CS role.















So how about we augment this somewhat - let's display some APIs to the successful candidate. 

I now add a REST connector to APIP CS.
I will leverage this to display some public APIs.

Here is the APIP CS api I need to call - a call example using Postman -


















I use the above url as the basis for my REST Connector definition in PCS -
















I have augmented the process as follows -

















I check out the public apis in my APIP CS Developer Portal -

As you can see, I only have one -
















I now deploy and test the process -

























The approver approves -

























I then see the public apis -

























I also get an email with a link to the APIP CS management or developer portal - depending on the role







Now this is a simple example of what one can do by combining Oracle PaaS Services.

You could augment this further by displaying the APIs from the developer portal and letting the user select one or more for API Registration.
API Registration involves creating an application within APIP CS and then registering the api with
the newly created application.

How would you go about doing that?

Begin by checking out the APIP CS REST API docs on docs.oracle.com




















I begin by testing this in Postman -


















I validate in API Platform Developer Portal -













I create a new connector in PCS for the APIP CS Mgt Service -
















Remember - the REST APIs are your oyster - go explore!

Saturday, August 12, 2017

#594 The Hare of the Dog Vol III now available on Amazon
























A veritable book of books, now available on Amazon.
Just search under my name - Niall Commiskey.

Buy all 3 volumes to get your very own Irish Flag -














Thursday, August 10, 2017

#593 Oracle Cloud Security Whitepaper




















Many customers moving to the cloud have questions vis-a-vis security.
This document is an excellent source for answering them.

Check it out here

Wednesday, August 9, 2017

#592 ICS / APIP CS Integration

Here is my ICS integration -

Simple stuff, just a REST interface to creating an organization in Service Cloud.



Here is the endpoint -
https://myICS/integration/flowapi/rest/NC_CREATEORG_REST/v01/createNewOrg?orgName=JelloBiafraInc

Before I can publish this API to APIP CS, I need to configure ICS for the target APIP CS platform.

As you can see, I have deleted some of the URL, but you get the idea.

Now, I go to activate the integration -



Let's see what other operations are available -



I'll go with Create New API.

I fill in the details as follows -


Note: the checkboxes for deploy and publish.

I check them -


Then I click Create.


Simple stuff!





















Tuesday, August 1, 2017

#591 ICS Map My Data lab


This is a simple lab that demonstrates all the functionality of the Map My Data pattern.











Available here

Monday, July 31, 2017

#590 - ICS roles

I get quite a lot of questions about the user roles available in ICS. Some of the questions relate to user access to data. For example, how do I prevent developers seeing payload values, such as credit card number.


The starting place for eliciting such information should be the ORCL docs - here I read



































Here are those roles in the cloud admin console -


















That's a lot more roles than detailed in the doc.
Suffice to say, many of these are cloud admin roles -
Identity Domain Administrator allows me to manage users etc.

Let's just concentrate on the following -


  • user
  • monitor
  • runtime

I will grant the user role to Uncle Paudge -




















I will grant the monitor role to Pat Mooney -


















I will grant the runtime role to Snowy Moran



















Now let's log in as the various users -

Uncle Paudge (Developer / user role) - 























He has access to all the top level components.
This is the optimal role for developers -
As the doc states -

Enables you to access all parts of Oracle Integration Cloud
Service to perform the following tasks:
• Create, deploy, and monitor integrations.
• Upload security certificates.

Now to the question, what if I do not want developers to see confidential info contained
in the payloads passing thru ICS?

At one level, the developer can do everything, well almost. She can log payloads, when activating integrations   -














But as you can read above, this is not recommended in a production environment.

Also worth noting, the developer with the user role can manage all of the settings -



















Best solution in this case, is to have a separate production environment. The developers can
do their stuff in the Development environment. Deploying to Production can be restricted. You could also use the REPL based Admin tool for ICS. This tool was developed by the Oracle A-Team and is detailed in a previous post.


I now log in as Pat Mooney the monitor -

Pat Mooney (Integration Monitor / monitor role)



 


















at first glance, it looks as if Pat has access to all components, but
let's click on integrations -








I click on Dashboard -











However, the monitor role does allow access to the settings -


















This is something you will have to keep in mind.

Let's now look at the runtime role -

Snowy Moran (mobile developer / runtime role)


Snowy develops mobile apps and needs to call ICS to access backend services.

He sees all the icons when he logs in, but cannot access anything.









But let's go to Postman and try the ICS REST API













First attempt, without any authorisation - I get Authorisation Required.

I add Snowy's credentials -


















As you can see, our mobile developer cannot just execute any ICS REST API.
The API I selected was on that lists all integrations on ICS.

He can only execute an ICS integration, with this role.

Here is one I prepared earlier -




















The URL is as follows -

https://myICSEnv/integration/flowapi/rest/NC_CREATEORG_REST/v01/createNewOrg?orgName=NiallCOrg

I execute this in Postman, using Snowy's credentials -


















Wednesday, July 19, 2017

#589 concise doc explaining all things Fusion Apps

For those of you who are somewhat confused by the world of Fusion Apps.
Read and be assuaged.



















Click here