Furious Bob

SLAs (Service Level Agreements) são acordos que ocorrem entre duas partes, normalmente entre clientes e provedores de serviço, que garante aos clientes uma qualidade mínima de um serviço. SLAs estão presentes em praticamente todos serviços que contratamos, você por exemplo, ao contratar um provedor de acesso, este deve lhe oferecer em contrato uma qualidade mínima de tempo de dispononibilidade e velocidade de navegação (embora meu provedor tenha a cara de pau de oferecer apenas 20% do valor contratado de garantia de banda).
Quando você estiver modelando o seu processo de negócio, em um determinado momemento de sua especificação, você vai esbarrar em uma SLA, como por exemplo o tempo máximo para um chamado de um cliente ser processado.
Sempre que ministro cursos de jBPM, uma pergunta recorrente é: o jBPM suporta SLA, a resposta é sempre a mesma: Não, o jBPM não suporta SLA, mas lhe oferece todos mecanismos internos para que você defina suas SLAs.
Uma coisa que gostaria de deixar bem claro, é que o jBPM é um excelente framework de GOP (Graph Oriented Programming) e para por ai :). Apesar de eu ser um grande entusiasta do framework, acredito que este nome (BPM) não reflete as características do framework (mas isso é estória para outro post).
SLAs são conceitos muito intrícicos ao seu negócio, colocar isso dentro do framework seria uma abordagem inocente de se tentar abraçar as diversas formas de negócio que existem. Embora alguns produtos de umas empresas de 3 letras >:) clamem que isto seja possível através de plugins e templates específicos por segmento de mercado :D.
Uma outra coisa que deve-se ter em mente quando você estiver mapeando seu processo é: SLAs não são métricas que você extrai do processo, elas são garantias!, é comum os usuários de BPM confundirem SLAs com KPIs (Key Performance Indicators). Você pode sim extrair algumas métricas de uma SLA como ASA (Average Time to Answer) e TAT (Turn Around Time).
Com esta breve introdução de SLAs e o que elas significam no processo, como podemos aplicar isto no nosso processo?
Vamos usar o processo que apresentei nos dois últimos posts para representar uma situação de SLA. Vamos supor que a cada 2 horas a minha tarefa aumente sua prioridade, aumentando assim a chance de a mesma ser vista pelo gerente que deve analisá-la.
Podemos fazer isso com o jBPM através da combinação de um timer e de uma action associada ao mesmo. No nosso processo original, vamos adicionar um timer que execute a cada 2 horas na nossa task. A listagem abaixo mostra isso:

19
20
21
22
23
24
25
26
27
28

<task-node name="Verificacao de Solicitacoes">
		<task name="Verificar Solicitacao">
			<description>
				Solicitacao de Hora extra funcionario #{identity.username}
			</description>
			<assignment pooled-actors="manager"></assignment>
			<timer duedate="2 business hours" repeat="2 business hours">
				<action class="com.furiousbob.action.TaskPrioritySLA"></action>
			</timer>
		</task>

Uma Task pode conter um sub-element timer que no nosso caso deve rodar a cada 2 horas de negócio. O jBPM suporta a noção de hora corrente, ou hora de negócio (business hours) Para maiores informações acesse a documentação do jBPM para timers.

O código responsável por aumentar a prioridade da task é apresentado abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

package com.furiousbob.action;
 
import org.jbpm.graph.def.ActionHandler;
import org.jbpm.graph.exe.ExecutionContext;
import org.jbpm.taskmgmt.exe.TaskInstance;
 
public class TaskPrioritySLA implements ActionHandler {
 
	public void execute(ExecutionContext executionContext) throws Exception {
		try {
			int currentPriority = executionContext.getTaskInstance()
					.getPriority();
			// Maximum priority of a given task is 1
			if (currentPriority > 1) {
				currentPriority--;
				TaskInstance t = executionContext.getJbpmContext()
						.getTaskInstanceForUpdate(
								executionContext.getTaskInstance().getId());
				t.setPriority(currentPriority);
			} else {
				// we could redirect the user to another node in the process if we want to.
 
			}
		} catch (Exception e) {
			e.printStackTrace();
		}
 
	}
 
}

Note que o código simplesmente aumenta a prioridade da task. Para nosso exemplo isto basta. Mas em um exemplo do mundo real você poderia, ao atingir a prioridade máxima, sair do nó corrente e ir para um nó onde o responsável seja alguem do backoffice por exemplo.

Combinando isto com o meu último post você pode criar uma aplicação poderosa onde as tarefas de maior prioridade são sempre exibidas em primeiro lugar, e garante que as tarefas não sofram de starvation, a medida que novas tarefas sejam adicionadas à lista do usuário.

Acredito que este pequeno exemplo possa demonstrar o quão poderoso o jBPM é para lidar com assuntos relacionados a processos de negócio, basta apenas executarmos alguns pequenos ajustes para que o mesmo trabalhe da maneira que gostaríamos.

Tenho na manga alguns tópicos bacanas, para apresentar em relação ao uso do jBPM como suíte completa de BPM, mas antes preciso apresentar alguns outros conceitos, fiquem ligados pois esta semana ainda pretendo apresentar o new kid on the block da jboss o Envers, em uma conversa semana passada com meu amigo Edgar Silva, discutimos umas idéias bacanas para um uso deste framework. Não perca o próximo post.

Inté!