ESS MSS import in Track

[former_member188073]

Hello Dear Team,

First of thanks a ton for answering and guiding throughout solving JDI issues..

Today here I come with some fundamental doubts that have resurfaced me with this new error.

I have been working on a reconstruction of an ESS MSS track.

I have observer that ESS MSS componets (standard) too go to assembly unlike other SAP components like PCUI. why so?

Now in my assembly previously failed DCs and ESS MSS components are assembling together since the past 2 hrs. Where do i check the logs and further troubleshoot if assembly is running and would run properly.

  Processed at (GMT)  Component  Label  Owner  State 
   
  
  
  
  
 
 2011/10/12 11:06:33 lntinfotech_EMPOWER_SC COMPONENT ASSEMBLY 287934 Assembly running 
 2011/10/12 11:06:33 sap.com_SAP_ESS 603 Level 7 Update ERP53PAT.01240607 SAP AG Assembly running 
 2011/10/12 11:06:33 sap.com_SAP_ESS 603 Level 4 Update ERP53PAT.08180421 SAP AG Assembly running 
 2011/10/12 11:06:33 sap.com_SAP_ESS DC ess~in~addr 283147 Assembly running 
 2011/10/12 11:06:33 sap.com_SAP_ESS DC ess~in~pdata 283147 Assembly running 
 2011/10/12 11:06:33 sap.com_SAP_MSS 600 Level 18 Update ERP05PAT.01040643 SAP AG Assembly running 
 2011/10/12 11:06:33 sap.com_SAP_MSS 600 Level 18 Update ERP05VAL.08300546 SAP AG Assembly running 
 2011/10/12 11:06:33 sap.com_SAP_MSS 600 Level 13 Update ERP05VAL.05161019 SAP AG Assembly running 

Further, process is stopped at repository import

Step Returncode Log 
Check-assembly assembled View Log File 
Repository-export Assembly running View Log File 
CBS-assembly Waiting for assembly View Log File 
Export Waiting for assembly View Log File 

The export repository log is blank

  400   Bad Request 
  SAP J2EE Engine/7.00  
 






  Log file parameter is missing 
  Details:   No details available

Varun Biswas

Edited by: Varun Biswas on Oct 12, 2011 3:19 PM

[former_member188073]

Thanks SHreyas,

Sorry took time to end this.

It was just matter of time, given the hardware constraints,it was just matter of time that the ESS-MSS components were taking. But I have Put shreyas Inputs to our management and have found great enthusiasm for upgrade and proper maintenance.

Anyways I would be moving out of this projects, hopefully would get to work with something better in the JDI river.

Thanks.

[shreyas_pandya]

Hi Varun,

From the logs that you have shown it seem that you have performed multiple assembly operations, and i am assuming may be just may be due to the scarsity of hardware resources the assembly is taking long time.

You can get the assembly logs in the assembly tab itself, if possible please provide some more logs.

When you perform/trigger the "Assemble" operation, a process of generating a single trasportable Unit known as Software component Archive (.SCA) begins.

During this process the Central Build Services (CBS) scans and collects all the successfully built archives present in the Consolidation Buildspace. Even if a single Development Component (DC) is found to be in broken state in the buildspace specific to the Software Component (SC) then, it terminates the process ultimately causing the Assembly operation failure.

So, for a successful assembly operation, you need to make sure that all the DCs present must go through a successful build operation. This make sures that all the DC present in your consolidation builspace will be clean.

You also need to understand here that if your track has 2 Software Components (SCs) then, there will be 2 separate Assembly operations specific to the individual SCs. As per the SAP's Component model SCs are the Unit of transports.

You can refer to the below mentioned blog for understanding the SAP's Component Model...

:[NWDI Empowered Landscape vs. Landscape without NWDI Setup|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/22919] [original link is broken] [original link is broken];

Also, go through the below blog for understanding...

:[Source Code Journey (NWDI under the Hood)|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/25521] [original link is broken] [original link is broken];

Regards,

Shreyas Pandya

[former_member188073]

Hello Shreyas,

Yes indeed there were multiple check-ins,

Due to certain conditions any hardware or software upgrade is not possible hence we are living with whatever is available.

The archives got deleted hence had to re-download ESS MSS SCAs and re-checkin multiple times. retored the systems as well.

Finally the components moved successfully through the track into the newly added runtime system (test). But here I have two basic questions.

1. Why did the newly checked-in ESS/MSS components go to Assembly queue.

2. Later i would be required to ad the fina runtime system (PRD) as well. What should be the approach here.

Regards,

Varun

[shreyas_pandya]

Hi Varun,

Following is the explanation to clear your doubts.

1. Why did the newly checked-in ESS/MSS components go to Assembly queue.

In NWDI Assembly is the only place where all the different chunks of your source code modifications are brought together in order to complile a Unit of Transport called SCA.

So when you Check-In the newly added ESS/MSS or any component for instance then, it is simply detected as a modification in you product by NWDI. Now whenever there's a modification or any addition of new components into the product then, it has to go through the assembly operation.

To understand this situation, imagine some two wheeler factory that is involved in the production of some Bike-X.

The Bike-X will be complete and ready for sale only, when all it's integral parts like engine, headlight, battery, breaks, speedometer etc... are assembled into a single and complete functioning machine.

Similarly, in NWDI, every single modification has to bypass the Assembly step.

And hence the final output that is produced in Assembly operation is the .SCA file, which is the only format that can be moved to next runtime systems.

2. Later i would be required to ad the fina runtime system (PRD) as well. What should be the approach here.

Please understand that runtime systems that you define in the track, only represent the target systems of deployment.

In simple meaning In your Runtime systems only your .SCA files will be deployed.

Consider the following Example...

there are 3 separate runtime systems defined in your track.

1) DEV

2) TEST

3) PROD

Now assume that you have NWDI installed on the same host where you have your DEV runtime system.

This means that DTR server-Workspaces and CBS-buildspaces will be on the DEV system only.

So, in above scenario after assmbly operation is over, the .SCA that is generated in assembly step will now appear under the TEST tab import queue, after the successful import into TEST signifies that the SCA is successfully deployed in TEST runtime system. Now the same SCA will be waiting for import into the PROD tab import queue. So once you import it into PROD tab it will get deployed into the PROD runtime system.

I hope you'll get the clarity now.

If the explanation satisfies your queries, then i request you to mark the thread as answered.

Regards,

Shreyas Pandya