Friday, February 1, 2019

Velocity - Prediction techniques - Scrum Refined

As a scrum master, we always need to best estimate or predict on the amount of work which team can finish in upcoming sprint.
When we have already ran scrum with same team for 4-5 iterations, then we can consider the velocity of team while estimating work for future sprint. Sometime we can average total number of burned story points in number of sprints, to get an average velocity of team.

However, there are some holidays (national or public) in next iteration where everyone would be on leave. Or, someone from team is going on long sabbatical leave etc. we need to be more good in prediction on how much work a scrum team would be able to finish. 


  • Ignore leaves. - if you going to planning for a year or so, then it would be feasible to consider holidays, however it would be best to acknowledge management that prediction is based on best of our knowledge. we may need to consider changes in plan later as we grow
  • Adjust leaves to full team - Lets say, if we have team of 6 members and avg velocity in last 2 weeks sprint was 50 story points. Now we would like to predict velocity for next sprint where 1 public holiday and 2 person is on 1-1 week planned leaves, means total man working days = (10 days*6person)- (2person* 5 working days leave) -(5person* 1 public holiday ) =45 days
Predicted velocity = Avg. Velocity* (planned working days/ Avg. working days)
Predicted velocity for 45days = 50*(45/60) = 37.5 ~ 37 SP

  • Adjust leaves based on skill - Let's say if 3 OSB developers out of 6 OSB developers are on leave for complete sprint. Also, 1 tester out of 3 testers is on leave for full sprint.
Since these are skill specific reduction in team, which ultimately will impact the through put of team in sprint. 
As 3 OSB developers out of 6 OSB developers on leave - means 50% reduction 
and 1 tester out of 3 testers is on leave - means 33% reduction
If we look at overall team, then 4 out of 9 member on leaves - means 44% reduction

Then in such case, velocity can be reduced in range from 33- 50% due to unavailability of resources. Here, we can consider larger proportion as an overall reduction for this sprint.


Friday, August 7, 2015

Reading Service Account Details in OSB using fn-bea:lookupBasicCredentials

In continuation to the last blog, we will see the second approach to read the credential details from a Service Account and pass these to target system. It is quite safe to use in OSB to save credentials and authentication.


  • create a service account, select resource type as "Static" and update the credentials.
  • create relevant proxy, biz services.
  • Now create one dummy Xquery selecting target schema structure, which will read created service account and assign value to target xml elements, named as lookupPassword.xq in my case as below
declare namespace ns0 = "http://www.example.org/sayHello/";
declare namespace funcLookup = "http://tempuri.org/ServiceAccountlookup/Funclookup/";
declare namespace ns1 = "http://www.example.org/request/";
declare namespace xf = "http://tempuri.org/ServiceAccountlookup/lookupPasswrd/";
declare namespace con ="http://www.bea.com/wli/sb/services/security/config";

declare function funcLookup:getUserName($usernameVar as xs:string) as xs:string
{
  let $data := fn-bea:lookupBasicCredentials($usernameVar)
  return
    if (exists($data/con:username/text()))
    then $data/con:username/text()
    else ""
};

declare function funcLookup:getPassword($passwordVar as xs:string) as xs:string
{
  let $data := fn-bea:lookupBasicCredentials($passwordVar)
  return
    if (exists($data/con:password/text()))
    then $data/con:password/text()
    else "as"
};

declare function xf:lookupPasswrd($newOperation1 as element(ns1:NewOperation))
    as element(ns0:NewOperation) {
       
            {funcLookup:getUserName("ServiceAccountlookup/ServiceAccount")}
            {funcLookup:getPassword("ServiceAccountlookup/ServiceAccount")}
       
};

  • Use the replace activity to assign output of above xq in $header variable.
  • Deploy and run the test, here is the Result 

Reading XML/Xquery (Password) file in OSB

Some days back, I came across a case where I need to pass the Username/password to target system in header of soap message, which will authenticate the request. This authentication will be used in lots of OSB services so can't be hard coded in each service as it will be big maintenance task in case of credentials change.

I got two ways to achieve this, probably third will come soon where my colleague is working.

First : Store details in XML/Xquery file and use it while doing header transformation.

  • Create a dummy xquery (.xq file) to save the details as below

declare namespace ns0 = "http://www.example.org/passwordDetail";
declare namespace xf = "http://tempuri.org/xmlLookup/passwordDetail/";

declare function xf:passwordDetail($password1 as element(ns0:password))
    as element(ns0:password) {
        sotiPassword
};
  • Read this .xq and assign to a variable using Assign Activity.
  • Use Replace activity to update header as below
  • Deploy and see the result as below



I will explain the second approach in my next blog here.

Saturday, July 11, 2015

Web Services Reliable Messaging (WSRM) in OSB

It can be achieved using WS transport protocol for the proxy/biz services, which will allow messages to be delivered reliably between distributed systems even if system, network failure occurs.

This is basically used for the wsdl + wsrm policy based communication. RM policy can be be the part of wsdl or attached separately using policy tab in proxy/biz service. If policy is not there either way, then error will be thrown.

Please note that policy without RM assertion also be errored. Policy used by other transport must not have RM assertions and we must use only one RM assertion for a WS-policy.

Below is the tags for RM assertion :



Quality of Service (QoS) will be always Exactly once for the proxy service based on the ws transport. We can set QoS using the tag  in RM policy. It can contain any of the below:

  • AtMostOnce
  • AtLeastOnce
  • Exactly Once
  • OnOrder

Saturday, July 4, 2015

OSB as Reliable Communication

How to make our OSB communication reliable ?? else it leads to loss of message or duplicate message reaching at destination.

Basically, there are two aspects which help us in reliable communication with OSB

  • XA DataSource for transaction
  • QoS (Quality of Service)
Before have a deep dive into these, we understand about Global Transaction in general. In a single global transaction, any fault within the osb service or composite will result in a complete rollback of all transactions. But important is, only systems which are part of global transaction will be rolled back. and So called Global Transaction.
On the other hand, if it is not global transaction and fault occurs in specific part say RouteNode and handled, then only that local transaction in RouteNode will be rollback, not other invocation in message flow. So we should be in Global Transaction if we want to make reliable Communication.

XA is the transaction which can be shared with multiple resources as JMS, JCA, direct binding. Although using messaging queue is always reliable as we can enable persistence but it is more nice if we use it using xa data source which will create global transaction. XA will use two phase commit so all resource either do a commit or a rollback together.

Using QoS we can control message flow to destination if it is a global transaction. There are two concepts here
  • exactly once: it is for reliability through message assurance, will deliver message only once if destination is the part of global transaction
  • best effort: if destination is not the part of global transaction then message can be delivered more than once if OSB process is retried.
If the sending and receiving application can detect failure/duplicate messaging then reliable communication might not be necessary.

We will see on WSRM (Web Service Reliable Messaging) specification describes a protocol (WS) for Reliable Communication, in my next blog

Sunday, June 28, 2015

Private OSB Service

Private OSB Service: Limited to OSB Server

Recently, I came across with the new requirement from my Client that Basic/Granular services should not be exposed to outer world on OSB server. These basic services should be used only by other OSB composites if required. 

There are, however, many transports which can be used to invoke OSB service as below: 
  1. http
  2. jca
  3. jms
  4. local
  5. sb
  6. ws
we will see local transport here which also supports proxy service design to achieve modularity.

Just do message modeling of Proxy and set the transport to Local and deploy it. While invoking this basic service from other Proxy service, you can use any publish,service callout or Routing option. It works well !!

Local transport based proxy service can only be invoked by other proxy service, not by client and which perfectly suites to my requirement. Local proxy service doesn't have URI.

Importantly, Local proxy service inherits (QoS) transactional behavior of invoking proxy service. So say, if it is best effort at invoking service then same Qos will be at Local proxy.

Additionally, it supports propagation of security (Message or Transport or Anonymous)

Local OSB service can be tested using OSB test Console. These can't be published to UDDI

Saturday, March 7, 2015

Fundamentals OSB

Asynchronous service in OSB : 

We need to define below in Route node where we want to receive callback
  • Edit Route node
  • Add assign activity to request flow
  • Inside assign replace soap header to below one : 
<soap-env:Header
xmlns:ns1="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<ns1:MessageID>ws:uniqueAddress</ns1:MessageID>
<ns1:ReplyTo>
<ns1:Address>http://localhost:8011/CallAsyncService/proxyServices/Call
SyncCompositeProxy</ns1:Address>
</ns1:ReplyTo>

</soap-env:Header>

and its done !!


Synchronous service in OSB : 

We can invoke synchronous web service from OSB in two ways..
  • Simple OSB invocation over HTTP or 
  • if we are specific to SOA, then we can use SOA Direct 

For SOA Direct, we have need to have SOA direct binding and to get the SOA direct binding we have Direct Binding Component in Component palette in BPEL after that just use create the Biz service using the same sync wsdl and later create proxy using the same biz.

and its done !!


Error Handling in OSB : 

  • First create error handler and inside error handler, create stage.  Create Publish activity in stage to call some service.
  • Then add replace activity and choose from fault message whatever u want to pass to service selected in publish activity. 
  • Then add Assign activity: fault message to body var of biz service. Also add reply activity after publish
and its done !!