Today at the #PaaSSummercamp, VBCS is on the agenda. We did a few labs from the VBCS learning path. Nice thing is that you can do it yourself as well.

One of the main goals of the OracleJET labs yesterday was to introduce you to CCA components. Since VBCS is mostly based on OracleJET (For the UI that is) it should not be too hard to add a CCA component from our OracleJET application into our VBCS application. So actually, I wanted to try just that.

If you go to your OracleJET application project, the CCA components are in the ${OJETProjectFolder}\src\js\jet-composites\:
First create a zipfile out of the component, just zip the folder:
(I like TotalCommander for this).
Then in the VBCS Designer tab, browse to the very bottom to find the Custom Heading:
And click the plus icon.
This will bring up a dialog in which you can drag and drop your zip file:
Click import and then the component should appear in the list:
Now it's ready for use.

Since it's a form-component itself, you can't add it to an existing Form-component.

To navigate properly I opened the Structure pane and add the component just before my Form component in the Edit Expense Report page, as a new GridRow:

I want to have it as a new GridRow, just before the current Expense Report Form. Now, after releasing the compnent, it is added to the screen, and it turns out to be visible too:

You now just have to link the fields to variable elements.
So select the component, and the fields will be shown as properties, that can be linked to data-object-elements:

Click on the (x) icon to link the CCA-property to a page-variable-element. Now, since the only variable I have is the ExpenseReport row variable, I use that to populate my fields. They don't make sense functionally, but that is what I have to work with at the moment.
I link first-name to ExpenseReport.name:

Then hire-salary to amount and hire-date to startDate. And that's it. The fields are populated directly in design and live mode. But running the page will show:
As easy as that...

Today the Oracle OPN #PaaSSummerCamp is started. And I have the privilege to join @GeertjanW to kick-off the Application Development and containers track with an OracleJET training.

OracleJET is Oracle's JavaScript Extension Toolkit, that bundles popular JavaScript frameworks in a toolkit (not a framework) that allows you to QuickStart a JavaScript project.

One of the advantages is that you don't have to bother about which Frameworks you should use and how to setup your project. Geertjan cooked up a workshop with a series of labs that introduces you to OracleJET up to the point that you have a working CRUD (Create, Retrieve, Update and Delete enabled) application.

It's all on GitHub and the nice thing is: you can do the labs too, even if you weren't able to come to the Beautiful Lisbon area and attend the #PaaSSummerCamp. You even don't need to go to Oracle OpenWorld to do this workshop, because it all can be found here. You'll learn how to quickly build a OracleJET 5.2.0 based application.

What do you need? Well, not much. A laptop or desktop computer will help of course. The lab will support you in installing:

• npm 5.6.0
• a json-server REST/JSON Mock server
• ojet 5.2.0 command line interface

You can use any IDE or source editor you want, for instance Notepad or Notepad++, IntelliJ or JDeveloper if you like. But I found Netbeans 8.2 very convenient for OJET Development. Note that Oracle is handing over Netbeans to the Apache Foundation, where NetBeans 9.0 just have been released.

One of the labs in our Weblogic Advanced Administration 12c course is about using domain templates. When revising the particular lab, we created a domain in Weblogic 12c and then created a template based on the domain. On recreation of the domain based on the template we get an exception:
This we get regardless of if we provide nodemanager details at the initial creation of the domain.

We did some investigation and found for instance this forum,  that gave a hint, but not a solution or workaround.

One important hint is the message 'config-nodemanager.xml: failed to parse the template!(/home/rcma/rcma_domain_template.jar): Parsing the config-nodemanager.xml failed!'. So it relates to the nodemanager configuration and the contents of the config-nodemanager.xml file in the template.

By the way, my colleague found that the same issue can also be experienced during pack and unpack, as desribed in Oracle support note 2311027.1. Here you can find that the problem in the config-nodemanager.xml is about the password. If you have a nodemanager password set in the domain's config.xml, it is encrypted with the domain's seed/salt. It can't be decrypted and read by the domain configurator or unpack tools, because they don't have the salt of the source domain.

So, what is the work-around or solution? I see two:

1. Following the before mentioned support note, you can replace the nodemanager password in the ${SourceDomainHome}/config/config.xml in the  <node-manager-password-encrypted>******</node-manager-password-encrypted> element with a clear text password. Do the same in the <nod:password>******</nod:password> element in the ${SourceDomainHome}/init-info/config-nodemanager.xml. 
2. Open the templates jar file:
   
   
   Then Extract the config-nodemanager.xml from it and edit it:

   <?xml version="1.0" encoding="UTF-8"?>
   <nod:nodeManagerInfo xmlns:nod="http://xmlns.oracle.com/cie/nodemanager">
     <nod:userName>weblogic</nod:userName>
     <nod:password>{AES}6eu/SDW2GBcb4R2lZgBD1hJVzN7UXQw+w4o46wfvHlk=</nod:password>
     <nod:nodeManagerHome>/app/work/domains/AA2Domain/nodemanager</nod:nodeManagerHome>
     <nod:perDomainNodeManager>true</nod:perDomainNodeManager>
     <nod:customLocationNodeManager>false</nod:customLocationNodeManager>
     <nod:manualNodeManagerSetup>false</nod:manualNodeManagerSetup>
   </nod:nodeManagerInfo>

   replace the password with something readable, for instance:

   <?xml version="1.0" encoding="UTF-8"?>
   <nod:nodeManagerInfo xmlns:nod="http://xmlns.oracle.com/cie/nodemanager">
     <nod:userName>weblogic</nod:userName>
     <nod:password>DoesNotNecessarilyBeAMatchingPassword2018</nod:password>
     <nod:nodeManagerHome>/app/work/domains/AA2Domain/nodemanager</nod:nodeManagerHome>
     <nod:perDomainNodeManager>true</nod:perDomainNodeManager>
     <nod:customLocationNodeManager>false</nod:customLocationNodeManager>
     <nod:manualNodeManagerSetup>false</nod:manualNodeManagerSetup>
   </nod:nodeManagerInfo>

   The password does not necessarily be the actual password of the source environment (at least with the template, not sure in case of pack/unpack). Then re-package the file into the template.

I tested the second work-around, not the one suggested by the note. I actually prefer the second option, since the first option suggest updating the source domain, which I'd rather prevent to do.
Since you do need to do a change, why not change the template? This we tested succesfully.

Another issue solved. Well, actually not really. This is a workaround and the Weblogic tooling should prevent this from happening. You should be able to enter a nodemanager password that is added to the template, or you should be asked for a password at unpack or domain creation. In fact, at creation of a new domain based on the template, you are asked for a nodemanager password. So, why would the domain configurator even bother about trying to read the nodemanager password and/or fail at parsing the file?

If I'd be so honoured to have this blog be read to a product manager or developer of Weblogic, could you take a look into this? Thanks!