um tempo atras, tipo uams duas semanas,

o Jamie Tompson postou um componente interessante pro SSIS.

 

 

Ele ajuda a normalizar dados vindos de arquivos texto emum formato não normalizado. afffff expliçãozinha 1/2 boca né?

 

mais é isso msm.. v lá no blog dele.

 

o componente do pipeline pega algo tipo:

SalesOrderNumber	OrderDate	Product	Quantity
SO49169	01/02/2003	Road-250 Black, 44	4
SO49169	01/02/2003	Road-650 Black, 60	1
SO49169	01/02/2003	Road-550-W Yellow, 38	2
SO49170	01/02/2003	Mountain-200 Black, 46	1
SO49170	01/02/2003	Men's Bib-Shorts, L	2

 

 

e transforma em outputs normalizados tipo:

 

 

OrderID	SalesOrderNumber	OrderDate
1	SO49169	01/02/2003
2	SO49170	01/02/2003

 

OrderID	Product	Quantity
1	Road-250 Black, 44	4
1	Road-650 Black, 60	1
1	Road-550-W Yellow, 38	2
2	Mountain-200 Black, 46	1
2	Men's Bib-Shorts, L	2

 

 

o pessoal q tava usnado achou uns bugs mais já tem uma versão mais nova. ( link no fim do post acima)

 

 

 

 

O grane mestre Jamie Tompson postou lá no blog dele hj uma coisa q mais dia menos dia pode ser bem útil:

Como determinar a versão do ssis.

 

 

 

 

 

guarda aí no canto q mais hora menos hora vai ser útil.

 

hhauahuahuahuahua

muito bacana..

tava aqui agora lendo o blog do pessoal da MS Brasil e vi q o pessoal vai liberar o fonte da base class library e algumas coisas que vão vir no 2008.! bem divertido...

 

 

bem bacana mesmo!

 

isso no SSIS ia dominar o universo mais aí tb é pedir d+ né..

hauhauhauahu

mais na época vo postar um POG cabuloso do SSIS pra usar SSAS como source. semana passada o pessoal precisou disso e foi hardcore.

 

Alguns problemas:

Transação na transformação

Mapeamento dos tipos retornados pela consulta MDX

 

fora esss cosias, como ultimamente o bixo ta pegando, ainda tem umas coisas do workflow pro MOSS que são bem interessantes.

 

 

 

 

 

 

Coisa interessante essa aqui.

Semana passada o gustavo tava querendo importar umas planilha , fazer umas transofrmações e usar o resultado disso porém, não queria usar um banco como staging pros dados. A idéia era transformar as informações e usar o output na aplicação.

 

Ai lembrei do estranho destination do tipo datareader.

 bacana q tem tipo uma implamentação do IDBConnection e IDataReader pro SSIS.

ai rola de pegar os dados, transformar da forma q vc quiser, mandar o resultado pro DaraReaderDestination  e na aplicação ler o resultset como se fosse uma conexão de banco comum. Bem bacana.

 

O artigo completo ta aqui: http://msdn2.microsoft.com/en-us/library/ms135917.aspx

 

mais pra resumir..

primeira coisa q tem q ser feita é referenciar o assembly do Microsoft.SqlServer.Dts.DtsClient lá na pasta bin do SQL 2005.

lá que ficam as classes de conexão, command, parameter.

 

A classe de conexào é a DtsConnection. Como era de se esperar, a classe espera  a connectionstring pra fonte de dados.

Nesse caso, a connectionString são os parâmetros do utilitário de linha de comando do dtExecui.exe

 

 

mais voltando ao connection, vc tem q dizer basicamente:

1) Onde o pacote está ( FileSystem, SQL, ou SSIS Package store)

2) o nome do pacote.

 

dtsConnection = new DtsConnection();
      {
        dtsConnection.ConnectionString = @"/FILE ""C:\...\DtsClientWParamPkg.dtsx""";;
        dtsConnection.Open();
      }

Nese caso acima, , executando um pacote no FileSystem.

 

Proxima coisa, criar o Command.

Existe lá no mesmo assembly, no mesmo namespace, uma classe DtsCommand.

 

Essa classe espera a conexão  e o commandText. O command text este caso tem que ser o nome do destination do seu pacote.

 

OBS: se o pacote tiver mais de um, não sei se funcionaria usar MARS ou algo parecido.

 

Ultima coisa, passar parâmetro se necessário.

Esses parameters do command, são as variáveis do pacote.

 

      dtsParameter = new DtsDataParameter("Country", DbType.String);
      dtsParameter.Direction = ParameterDirection.Input;
      dtsCommand.Parameters.Add(dtsParameter);

      dtsParameter.Value = countryName;

pronto. feito isso, só chamar o executereader no command e usar o resultado.

 

Tem alguns pontos importantes a se considerar:

1)primeira coisa é onde o pacote está.

não dá pra executar da máquina X , via API, um pacote hospedado na máquina Y. Pra isso tem que fazer um módulo POG.

2)Pra isso funcionar, o DelayValidation do dataflow e dos objs pais deve estar falso. ( ) vai entender...

3) CUIDADO com o método Read retornado pelo command.... a documentação tem um OBS bizarrào a este respeito...

Diz eles que o Read continua voltando True uma ou mais vezes após a ultima linha ser lida do resultset... hauhauahuah então tá...

Essa q é a beleza da abstração... o bagulho funciona assim e ponto.

então o negócio é  abstrair...

 

Important:

The Read method of this implementation of the DataReader returns true one more time after the last row of data has been read. This makes it difficult to use the usual code that loops through the DataReader while Read returns true. If your code attempts to close the DataReader or the connection after reading the expected number of rows, without an additional, final call to the Read method, the code will raise an unhandled exception. However, if your code attempts to read data on this final iteration through a loop, when Read still returns true but the last row has been passed, the code will raise an unhandled ApplicationException with the message, "The SSIS IDataReader is past the end of the resultset." This behavior is different from that of other DataReader implementations. Therefore, when using a loop to read through the rows in the DataReader while Read returns true, you need to write code to catch, test, and discard this anticipated ApplicationException on the last successful call to the Read method. Or, if you know in advance the number of rows expected, you can process the rows, and then call the Read method one more time before closing the DataReader and the connection.

 

aí pra esse tipo de implementação, tudo q ta nos posts anteriores sobre identidades, restrições físicas continua valendo..

num deixa de ser uma opção interessante.

 

dá pra usar o pacote tb como fonte de um relatório no Repoting services...

 

 

 

 

Outro dia tava asistindo coisas aleatórias na TV e vi na sony o the IT Crowd.

como nos 500 mil canais num tava passando nada que prestasse parei pra ver. Putz! simplesmente hilario aquilo... produção toska.. mais muito engraçado.. huahauhauhua.

vale a pena olhar. Passa na sony terças la pelas 8 ou 8 e 30. algo do tipo...

 

 

ainda bem q a mid season ta acabando... semana q vem tem o retorno de atlantis... dia 28 se não me engano.. heroes tb.. e house...

ai tudo volta ao normal..

 

Uma coisa interessante que aconteceu em um cliente semana passada:

O cliente tem uma infra rande pro SQL 2005 instalaod em um failover cluster e o serviço de SSIS está em uma máquina separada.

Ele instalou normalmente o serviço e ao tentar publicar os pacotes no MSDB, não conseguia.

Pesquisando a respeito, encontramos duas coisas interessantes:

1) vc pode alterar o server no xml de configuração do serviço pra apontar pro outro banco de dados. Porém contudo entretanto, um pequeno problema aparece;

 

2) O SSIS, quando instalado em máquinas separada do DB , gera uma pequena dor de cabeça com o repasse de credenciais ( na verdade ele não repassa a credencial. Olha só:

 

SQL Server 2005 Integration Services (SSIS) does not support the delegation of credentials, sometimes referred to as a double hop. In this scenario, you are working on a client computer, Integration Services is installed on a second computer, and SQL Server is installed on a third computer. Although SQL Server Management Studio successfully passes your credentials from the client computer to the second computer on which Integration Services is running, Integration Services cannot pass your credentials on from the second computer to the third computer on which SQL Server is running.

o que quer dizer q , apesar de vc se conectar com o management studio passanod a sua credencial, se o seu package acessa o databse usando integrated security, os erviço do SSIS não vai passar a credencial pro servidor onde o databse está.

 

 

 quando a coisa for resolvida direito posto o resultao da briga....

bem q o pessoal do sql podia consertar essa pequena feature do produto... ia resolver milhões de aborrecimentos e economizar um tanto bom de gambiarra...

 

 

Então,

as bandas de sempre tao enchendo o saco ja ... ontem tava eu escutando o programa do mauricio valadares na radio indo embora e eles tocram duas obras de arte.

 

1) um povo da etiópia q toca jazz cabulosamente bem... (eh isso mesmo.. c leu certo.. etiópia....)  CD AQUI

2) The allman Brothers band ... hauhauahuahu o cara da guitarra é fodão nível hendrix... mto bacana!

 

Finalmente,

scifi channel veio pro brasil! conmeçou a transmitir semana passada já rolando umas coisas bacanas..

primeiro o bom e valho stargate SG1. Mais como tudo na vida, nào se pode contrariar a regra universal. os caras tào transmitindo o SG1 dublado. putz... bem tosko.

 

e essa sexta começa o Flash Gordon!!!!! hauahuahuahuahau só na base do download it all!

 

hehehhehe

acabou stargate SG1 na décima temporada... osso... dificil achar uma coisa bacana hj em dia.

mais pra alegria geral a MGM lançou um box em pre-venda na amazon com TODAS as tempoardas juntas!

 

tipo 54 DVDS!

 

 

td isso por módicos 210 cruzeiros americanos!

 

 

Problemas... coisas simpels ficando cabulosas.

 

 

 

O Requisito até que é simples.

 

1) Existe uma aplicação web onde, o usuário dará o comando para iniciar a execução do pacote SSIS.

2) A interface do usuário deverá mostrar o andamento da execução do ETL.

 

:D

 

Os problemas começam ao olharmos para a distribuição física dos servidores.

Maquina 1: SQL Server 2005 Database Engine + SSIS

Máquina 2: Windows 2003 Server (ASP .NET app Server)

 

Bem, ao tentar escrever a rotina que execute o pacote ETL a primeira vista parece ser bem simples.

A primeira coisa que aparece na sua cabeça na reunião com a gerência :Existe uma API gerenciada pra isso! bem fácil.

 

A primeira coisa que se esbarra é no fato de não dar pra rodar um pacote que está em uma máquina remota através da API.

A MSDN dá duas sugestões pra fazer isso funcionar.

 

A primeira e, geralmente inútil pra não chamar de toska é rodar o pacote em um job e a aplicação starta o JOB. A tosqueira dessa opção é o controle ou melhor, a falta dele sobre o pacote.

 

A segunda opção, a primeira vista bem bacana é: Escreve um Web Service que faz o trabalho pra vc, coloca ele na máquina do SSIS e a sua aplicação chama este Web Service.

 

 

De novo, o primeiro pensamento: aff.. bom tb.. só fazer o WS, 2 horas a mais de esforço ... nimguém vai morrer por isso.

 

Web Service Funcionando pra executar o pacote, na hora de testar começam os problemas de verdade.

 

A raiz dos problemas que aparecem estão relacionadas ao contexto de impersonate no qual o pacote é executado.

 

Por padrão, uma aplicação Web é executada no contexto de um working process.

No windows2000/XP o usuário que executa a aplicação é, por padrão o ASPNET na máquina local. no 2003, este usuário é o usuário do application pool (por padrão network service).

 

Dito isso, os problemas que aconteceram comigo quando tentei executar o pacote via web service foram:    

 

1) SSIS não consegue carregar o pacote e retorna o erro : Package errors encountered: Code = -1073651690; Description = Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available.

Isso vai acontecer pq ,por padrão os dados sensíveis do pacote são criptografados com a chave do usuário que o criou. Quando eu faço o deploy deste pacote e tento executar através do web service (sem o impersonate do ASP .NET), o usuário que está fazendo a operação não é o meu e sim o usuário do Worker Process.

Então, se eu usasse o impersonate, funcionaria? Bom, funcionaria se o usuário que criou o pacote o executasse através da aplicação web. Os demais usuários não conseguiriam executar o pacote.

 

Veja o artigo da KB que fala disso:

 

Uma opção boa pra esta situação é criptografar os dados sensíveis do pacote com uma senha e passar esta senha pra instância de Application antes de fazer o Load no pacote.

 

algo tipo:

 

Package myPackage;

Application integrationServices = new Application();

if(packagePassword != "" && packagePassword != null){

    integrationServices.PackagePassword = packagePassword;

}
....

myPackage = integrationServices.LoadPackage(....,...,);

 

Problema 1 resolvido. Agora consigo carregar o pacote.

Ao Executar o pacote, no meu caso, tive problemas com manipulação de File System e permissões de banco.

Porque? Bom, primeiro porque, se voltarmos ao problema do impersonate, a identidade que está executando o pacote agora não é a minha e sim a do worker process.

A próxima tentativa para solucionar isso foi colocar impersonate nas minhas duas aplicações web.

A primeira delas, a interface propriamente dita, a segunda o web service. Assim, o pacote seria executado com o usuário que, em teoria tem as permissões necessárias pra manipular o file system e o banco.

Aí vem o segundo problema.

Quando executo o pacote, não funciona e deveria... hehehe

ao Habilitar o LOG do pacote para mostrar todas as operações, o log me mostra, nas primeiras linhas, o meu usuário (resultado do impersonate).

Daí pra frente pipocam milhões de linhas onde o operator ( quem está executando a operação) é o Network Service.

bem bizonho.

Procurando com calma na technet, um cara da MS diz que, o Integration, que por padrão abre várias threads pra executar as operações em paralelo, não repassa o contexto do impersonate entre as threads.

 "The impersonation applies to the calling thread only, but SSIS creates additional threads in order to be able to perform multiple steps simultanously. Unfortunately, the impersonation context is not passed to these additional threads, so any data base access occurs under process user context, not under impersonated context."

 

 

 

Please see the following post by Bob Bojanic on the SSIS development team: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1855810&SiteID=1

It seems that a change to the CLR has caused binary incompatibilities between assemblies and the VB runtime.

To ensure you are not affected, be sure that you have SQL Server Service Pack 2 (SP2) installed.

http://www.ssistalk.com/

 

hj descobri uma coisa bacana...

tava usando uma File System Task pra mover arquivos texto pra um diretório de backup no ETL e precisava setar a connection de origem e destino da task.

 

Neste caso, eu tenho uma pasta digamos em c:\temp\ETL

meu pacote precisava afzer toda a importação e depois mover estes arquivos para c:\temp\ETL\importados\yyyymmdd

 

Então, dentro de um Container For Each no meu diretório coloco uma File System Task pra afzer o Move.

o problema começa na configuração da task. Como eu faria pra falar pra ele: Mova o arquivo c:\temp\ETL\abc.txt pra minha pasta de importados.

 

Como escrevedor de código o primeiro pensamento foi algo do tipo: cria uma script task e seta o valor da variável lá.

 

Dando uma pesquisada descobri a coisa interessante.

 

fica meio escondido la na janela de propriedades. Uma variável do SSIS pode ser configurada para avaliar uma expressão.

Isso quebra um galho absurdo.

 

pra usar isso basta selecionar a variável, definir o EvaluateAsExpressionpra true e frango! coloca a expressão lá que funciona!

 

só sei de uma coisa... esse povo do SQL teve a manha no SSIS. Sem comparação com os malditos scripts VB do DTS de 500 milhões de linhas!