The IT Consultant Guy
Talking about business process management, workflow, CRM, and things that bug me.
Thursday, August 2, 2012
Goodbye Buick
- Small Interior
- Short Rear Legroom
- 4-Cylinder Engine
- Mid-Grade Dashboard
- Torquey Steering
Why is GM doing this to the Buick? It's supposed to be synonymous with high end quality.
(Hint: It's called the Endeavor, but should be called the Pontiac)
Tuesday, April 20, 2010
Reduce PRPC Activity complexity: Use the question mark operator
The following description can be found in Java tutorial section found here:
Another conditional operator is ?:, which can be thought of as shorthand for an if-then-else statement. This operator is also known as the ternary operator because it uses three operands. In the following example, this operator should be read as: "If someCondition is true, assign the value of value1 to result. Otherwise, assign the value of value2 to result."
Here is a simple example. We have a class "Test-Work" with two properties: BenefitCode and PayableBenefit. When the BenefitCode equals ENHANCED then the PayableBenefit is assigned $100, else PayableBenefit is assigned $50. (For this exercise we are assuming BenefitCode must be calculated progmatically and NOT declaritivly)
In out first activity, StandardActivity, we check whether or not BenefitCode is ENHANCED. If it is then PayableBenefit is assigned $100 and the activity exit. This requires two steps. The first one contains a Precondition, a Property-Set, and finally a Transition. (Not shown) The second Property-Set assigns the exception.

The second activity, QuestionActivity, accomplishes ALL of the above with a single Property-Set, and it does it without any Preconditions or Transisitions.

The ternary operartor is frowned upon by some programmers since it tends to compress a lot of code into a little space, making the program harder to understand. In PRPC removing Preconditions and Transitions tends to clarify the process, and this is exactly what the operator does.
Monday, April 20, 2009
How to do REST on Oracle SOA Suite
Ok, so your company ponied up and purchased Oracle SOA Suite and now you have to make it dance. We'll the hottest thing going right now is REST (Representation State Transfer) and all the cool kids are doing it. You want to be cool right?
Anyway, REST is a framework the puts forth rules on how transactions are governed. Among the benefits offered by REST are scalability, caching of content, and reduced server load. The best example of this framework in action is the HTTP protocol. The SOA Suite, however, tends to use the SOAP protocol, which doesn't mean you can't use REST, but it also tends it promotes bad habits.
So how can I learn this crazy REST thing you say? Well we are going to bind our services to HTTP instead of SOAP; ensuring that our services are REST by default.
We are going to design a service that takes a purchase order and returns a simple response. This example used the Order and OrderSimpleResponse supplied by the UBL data model which can be found here: http://www.oasis-open.org/committees/ubl/.
Now, create a new application "PurchaseOrderBPELApplication". Inside of this application create a new synchronous BPEL project "PurchaseOrderBPELProcess". On the last screen of the wizard you can pick your input and output variables. Go ahead and pick the UBL Order for the input. Don't bother with the output, we'll fix that soon. There is a bug in jDeveloper which will prevent it from working right.
Ok, good. Now let's bring all of the "common" UBL XSD files into the project as well as the UBL-Order-2.0 and UBL- OrderResponseSimple -2.0. jDeveloper needs a local copy to deploy these properly. Keep these XSDs in their relevant directories. After you are finished your application tab should look like this:
Now we have to fix the response message so that it returns the OrderResponseSimple.
- Add the new namespace for OrderResponseSimple.
- Add an import for OrderResponseSimple.
- Change the schema location for both the request and the response.
- Change the response message element.
Open up the WSDL and doctor it as shown.
<definitions name="PurchaseOrderBPELProcess"
…
xmlns:ns2="urn:oasis:names:specification:ubl:schema:xsd:OrderResponseSimple-2
…>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TYPE DEFINITION - List of services participating in this BPEL process
The default output of the BPEL designer uses strings as input and
output to the BPEL Process. But you can define or import any XML
Schema type and use them as part of the message types.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<types>
…
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="urn:oasis:names:specification:ubl:schema:xsd:Order-2"
schemaLocation="maindoc/UBL-Order-2.0.xsd"/>
</schema>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="urn:oasis:names:specification:ubl:schema:xsd:OrderResponseSimple-2"
schemaLocation="maindoc/UBL-OrderResponseSimple-2.0.xsd"/>
</schema>
</types>
<message name="PurchaseOrderBPELProcessResponseMessage">
<part name="payload" element="ns2:OrderResponseSimple"/>
</message>
Almost there. Now we have to tell the BPEL to use and HTTP binding the WE define. Not the SOAP one it will attempt to generate. Add a concrete binding clause and service end point to the service WSDL file. We also need to add two new namespaces which will define the binding. The final WSDL will look like this.
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="PurchaseOrderBPELProcess"
…
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" >
…
<binding name="PurchaseOrderBPELProcessHTTPPost" type="client:PurchaseOrderBPELProcess">
<http:binding verb="POST"/>
<operation name="initiate">
<http:operation location="/initiate"/>
<input>
<mime:mimeXml part="payload"/>
<mime:content type="text/xml"/>
</input>
<output>
<mime:mimeXml part="payload"/>
<mime:content type="text/xml"/>
</output>
</operation>
</binding>
<service name="PurchaseOrderBPELProcessHTTPPostService">
<port name="PurchaseOrderBPELProcessHTTPPost"
binding="client:PurchaseOrderBPELProcessHTTPPost">
<http:address location="http://${hostname}:${http_port}/httpbinding/${domain}/HTTPPostService"/>
</port>
</service>
Finally, the bpel.xml needs to be modified. A noAlterWSDL="true" needs to be added or the app server will attempt to SOAP up the service.
<BPELProcess id="PurchaseOrderBPELProcess"
src="PurchaseOrderBPELProcess.bpel" noAlterWSDL="true">
Now deploy and test.
